16:05:36 <tsoome_> the clang 13 is having interesting issues with our asm files. would be nice to have clang 15 to see how much it can grok....
16:08:23 <jperkin> feel free to grab it from pkgsrc
16:22:24 <tsoome_> aha, cool
17:20:20 <nbjoerg> or godbolt
17:51:21 <danmcd> oooh, I didn't know about godbolt, that's neat.
17:56:51 <gitomat> [illumos-gate] 15459 loader: selecting menu entry can still leave cursor disabled -- Toomas Soome <tsoome⊙mc>
19:33:48 <andyf> Would anyone else like to look at illumos 15167 (fenix)? @danmcd I hope this is merely merge limbo rather than merge hell for you (and I can help when it gets integrated)
19:33:50 <fenix> BUG 15167: Panic when halting a zone with self-created links (In Progress)
19:33:50 <fenix> ↳ https://www.illumos.org/issues/15167 | https://code.illumos.org/c/illumos-gate/+/2662
19:55:03 <danmcd> Looking forward to this merge-heck, but not until we cut 20230309 tonight.  :)
20:02:37 <richlowe> tsoome_: I have clang 15, what do you wonder
20:02:50 <richlowe> if it's the thing we talked about, I think you'll have to just fix it.
20:03:29 <richlowe> I think omnios has clang 15 too
20:03:31 <richlowe> and pkgsrc
20:11:15 <richlowe> yeah, with the thing we talked about fixed by the perl I gave you, things seem ok?
20:11:26 <richlowe> but I don't have a clang environment so I can only spot check
20:13:00 <sommerfeld> andyf: I'm looking at it now, but don't wait for me if you think it's ready to integrate.
20:14:26 <richlowe> tsoome_: and as I said, if you're able to let it fit with my vague schedule, I can do the comment fix for you.
20:22:51 <andyf> sommerfeld - thanks, I think it is and I know Robert has been through it including a comparison with what is in SmartOS. More reviews while I write up the tests notes would not hurt.
20:39:14 <tsoome_> richlowe there is actually more issues. some unknown instructions, some other errors too.
20:39:53 <tsoome_> richlowe and if internal as is disabled, it wont use cpp:D
20:40:12 <richlowe> you're going to have to show me those then.
20:41:18 <tsoome_> for example, it did not like 'jmp %cs:label'
20:43:45 <richlowe> I'm pretty sure I don't either. :)
20:52:35 <tsoome_> the error is: error: unknown use of instruction mnemonic without a size suffix, intel/kdi/kdi_asm.S:648 jmp %cs:dbgtrap
20:56:41 <tsoome_> or this: i86pc/ml/mpcore.S:108:2: error: instruction requires: 64-bit mode
20:58:48 <richlowe> I believe the kdi error is because of the superfluous %cs prefix
20:58:56 <richlowe> and clang is probably wrong about not just ignoring it.
20:59:01 <tsoome_> yep, it does build it without
20:59:05 <richlowe> I'm not certain though.
21:00:38 <tsoome_> intel/ml/copy.S:1139:4: error: invalid instruction mnemonic 'sstoq'
21:01:20 <tsoome_> intel/ml/ddi_i86_asm.S:43:7: error: invalid operand for instruction: inb (%dx)
21:01:33 <jbk> not critical.. but there's probably a few places where we use the raw bytes instead of a mnemonic (presumably because one of the assemblers at the time didn't know about the instruction)
21:01:42 <richlowe> yeah, that's not these places.
21:01:46 <jbk> (something that might be nice to fix in it's own ticket)
21:04:17 <richlowe> unfortunately the copy.S one hits instructions dis also doesn't support.
21:05:04 <richlowe> stosq probably should just be stos, and clang doesn't like a q suffix
21:05:42 <richlowe> I have no idea what's up with inb (%dx)
21:06:09 <tsoome_> same was for outb. 
21:06:28 <richlowe> perhaps it wants it spelled in (%dx),%al like objdump disassembles it?
21:06:48 <tsoome_> hm. good point.
21:07:05 <richlowe> you'd definitely want to test the heck out of all this and check disassemblies 
21:08:06 <tsoome_> yep. both mdb ::dis and objdump;)
21:08:18 <richlowe> we should probably figure out what dis hates about copy.o
21:08:26 <richlowe> lemme see if I can pin that down and file a bug while I remember.
21:09:03 <richlowe>      770:	60                   	(bad)
21:09:10 <richlowe> seems like it's just busted.
21:09:54 <richlowe> oh, there's data in there
21:09:58 <richlowe> wowee
21:11:57 <gitomat> [illumos-gate] 15460 elfcap.chk should refer to the right symbols -- Richard Lowe <richlowe⊙rn>
21:12:02 <richlowe> sorry this made life harder on you tsoome, but it looks like it's going to make us better, too?
21:12:17 <tsoome_> that was not your doing :D
21:12:26 <tsoome_> it was all there...
21:12:41 <richlowe> it looks like on FreeBSD they explicitly give inb a destination
21:12:42 <richlowe>  always.
21:13:00 <richlowe> all, 12 times or so they use it...
21:13:06 <tsoome_> yes, just tested it, inb     (%dx), %al makes it happy
21:13:19 <richlowe> there's one 'inb <immediate>' in loader
21:13:25 <richlowe> (freebsd)
21:35:58 <rmustacc> richlowe: If dis is missing something, can you file a bug for me and I clean it up?
21:36:38 <richlowe> rmustacc: it turns out that copy.S has data in the text segment, dis isn't missing something, it's just shitting itself more safely than objdump
21:36:43 <richlowe> which picks up again, perhaps dubiously.
21:37:00 <richlowe> moving that data to be data would be good, but I very much don't want to mess with hand-optimized bcopy
21:37:28 <richlowe> https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/intel/ml/copy.S#L300
21:47:52 <richlowe> does anyone of a fine vintage know if there are reasons which(1) being csh actually has compatibility implications?
21:48:14 <richlowe> I know all about the wonderful bugs and quirks and NFS badness it has had a role in, but not if there's a reason it never just got replaced.
21:48:37 <richlowe> alanc: ^
21:51:27 <alanc> lrwxrwxrwx   1 root     root          16 Oct 17  2018 /usr/bin/which -> ../gnu/bin/which*
21:52:16 <richlowe> wow, even sufficiently fine to just use the GNU one
21:52:27 <alanc> I believe which was csh because it was developed for csh users originally, since sh/ksh/etc. had type/whence/etc.
21:52:28 <richlowe> thanks
21:52:58 <alanc> we switched to gnu which for 11.4
21:53:35 <richlowe> I assume we'd switch to a BSD one, for reasons, but that's certainly a relief
21:53:44 <richlowe> in that I don't have to learn of any csh-y quirks that might matter.
21:53:46 <richlowe> or bribe danmcd 
21:54:01 <danmcd> Huh what?
21:54:14 <richlowe> danmcd: you're the only t?csh user I remember.
21:54:18 <danmcd> Ah.
21:55:03 <danmcd> I still like tsoome_'s idea of replacing csh in gate with tcsh, FWIW.
21:55:23 <richlowe> I prefer removing it and letting distributions ship tcsh, but yes.
21:55:24 <alanc> Looking at our PSARC logs, switching to gnu which was part of the prep work for our planned replacement of csh with tcsh by the time we shipped Solaris 13, since tcsh uses its own builtin which
21:55:58 <alanc> we got as far as making /usr/bin/csh a mediated link that can point to either /usr/bin/tcsh or /usr/sunos/bin/csh
21:56:33 <andyf> I would not put tcsh in gate, but distributions could switch it out or provide a mediated package
21:56:39 <richlowe> yeah, I'm with andy.
21:56:45 <richlowe> and we could mediate it right now.
21:57:01 <richlowe> (and we can replace which(1) right now, orthogonally)
21:58:20 <alanc> our planned Solaris 13 would have been such fun - removing UFS, SVM, NIS, 32-bit ABI, csh, bourne shell, and other legacy that wasn't worth making Y2038 safe - might have even finally bumped uname to 6.0
21:58:31 <alanc> but those plans are all ripped up and thrown away now
21:59:22 <richlowe> There are chunks of that happening here
21:59:28 <richlowe> but because I'm lazy.
21:59:31 <richlowe> if that makes you feel better
22:00:30 <alanc> heh, for us, it was being lazy on an instutitonal scale, and trying to avoid any work on those areas
22:03:11 <alanc> and we had no plan to remove sun4v (just sun4u here) , so you're ahead of us in the forced retirement department
22:09:44 <danmcd> I'd love to rip out UFS and other Y2038-unsafe things. But I'm apparently slave to whatever the #%*& glibc does.
22:10:04 <danmcd> Okay, that's a bit strong, but glibc's approach to Y2038 might be worth it.
22:10:37 <richlowe> the "large time" approach is good, because we're probably stuck with 32bit x86 forever.
22:10:45 <richlowe> (to be kind to users)
22:11:25 <richlowe> but there's a lot of things on the list that are both difficult, and not worth the effort of, making 64bit clean.
22:11:33 <richlowe> at some point I'm going to write up what would be on the chopping block
22:11:41 <danmcd> How many of our users, at this point, aren't either just using pkgsrc, omnios-extra, or OI's extras?
22:11:54 <richlowe> but it's so long-term, that there's no rush for me to write it up, really.
22:12:06 <danmcd> All of those are, AFAICT, doing 64-bit. (or can w/o pain.)
22:12:17 * danmcd thinks about illumos-extra when saying that.
22:12:38 <richlowe> I mean, that's very much a distro thing, so that's on y'all :)
22:17:01 <richlowe> I guess to be clearer, what I'm trying to say was "64bit only systems will almost certainly exist, but it's likely that some distributions will need 32bit x86 userland to live for practically ever"
22:18:19 <paulf> i386 is still limping along on FreeBSD and still has users
22:19:12 <tsoome_> about to die there too.
22:19:15 <toasterson> i't mostly for libs and some applications just not getting 64bit properly going.
22:19:37 <paulf> just about the only platform I know that is still creating i386 kernel and userland
22:20:05 <richlowe> yeah, I was trying to explain to Dan that my concern is more software that requires it, than people that require it, and unlike alanc we're not in a position to say "Stick running the 12 updates"
22:20:19 <richlowe> because except omnios, who I presume don't want to maintain an LTS for years and years, nobody does that here
22:20:57 <richlowe> I think it's more likely people will miss something we don't bother to port to 64bit, than they miss actually being 32bit.
22:21:00 <richlowe> if that makes sense? words are bad.
22:22:32 <alanc> our current big blocker to UFS removal is that the installer ramdisk is still UFS, because no one has figured out how to make it use ZFS off a ramdisk
22:24:26 <richlowe> jclulow has fixed that for us
22:24:42 <richlowe> and I think we only use a UFS boot archive as a last resort now.
22:24:43 <alanc> (well that, and the fact we only publish "dot-dot" micro releases now, and removing UFS in a micro release doesn't feel right)
22:24:43 <jclulow> Yeah we're using a ZFS ramdisk
22:24:59 <danmcd> Oooh, I'm going to need to bring that over jclulow
22:25:01 <jclulow> I should probably get the rest of that upstream 
22:25:23 <alanc> but as illumos has no releases, you don't have that problem - no illusion of release taxonomy to maintain
22:25:40 <tsoome_> cpio for boot archive:)
22:25:43 <richlowe> just a general sense of empathy.
22:25:52 <richlowe> both better, and worse, than release taxonomy.
22:25:56 <jclulow> Yeah I think it's true we don't have releases like Solaris had
22:26:06 <jclulow> But we try to manage the same kinds of removals and additions anyway 
22:26:35 <jclulow> While organising with distributors who themselves have releases and schedules
22:28:56 <jclulow> danmcd: There are some remaining design issues to nail down to make it something that will work for SmartOS
22:29:28 <richlowe> if someone wanted to 64bit-ize things in illumos-gate, that wouldn't be unappreciated!  Just keep in mind that, for a lot of it, there's a reason it's not done. 
22:29:31 <jclulow> In particular, what I'm proposing is actually a new module hook right before vfs_mountroot(), where if you set a particular boot property we'll load a particular module and use it to find the ramdisk
22:29:47 <richlowe> if you look at arm64-gate, you'll even find a list of things not done, for reasons.
22:29:49 <jclulow> In the SmartOS case I expect that module could be as simple as "look at the multiboot modules to find the right one"
22:30:31 <richlowe> and also keep in mind that a lot of it isn't as easy as it seems, because the code is doing really bad things, making it work is much harder than making it compile, often.
22:30:37 <jclulow> (you'll end up with _both_ a cpio archive, from which we get the drivers and the "zfs" module, and so on) _and_ a ramdisk (to import as rpool)
22:31:58 <jclulow> In the oxide arch we have a module that actually locates an NVMe device, or speaks on the network, or through our SP, to fetch the ramdisk, but that's all very specific to our environment etc
22:32:10 <jclulow> For SmartOS you'll want something multibooty
22:32:21 <danmcd> Of course.  And yes I'll def. want something multiboot2-y.
22:32:24 <richlowe> not half-assed, but two-assed.
22:32:29 <jclulow> lol