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....

feel free to grab it from pkgsrc

aha, cool

or godbolt

oooh, I didn't know about godbolt, that's neat.

[illumos-gate] 15459 loader: selecting menu entry can still leave cursor disabled -- Toomas Soome <tsoome⊙mc>

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)

BUG 15167: Panic when halting a zone with self-created links (In Progress)

↳ illumos.org/issues/15167 | code.illumos.org/c/illumos-gate/+/2662

Looking forward to this merge-heck, but not until we cut 20230309 tonight. :)

tsoome_: I have clang 15, what do you wonder

if it's the thing we talked about, I think you'll have to just fix it.

I think omnios has clang 15 too

and pkgsrc

yeah, with the thing we talked about fixed by the perl I gave you, things seem ok?

but I don't have a clang environment so I can only spot check

andyf: I'm looking at it now, but don't wait for me if you think it's ready to integrate.

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.

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.

richlowe there is actually more issues. some unknown instructions, some other errors too.

richlowe and if internal as is disabled, it wont use cpp:D

you're going to have to show me those then.

for example, it did not like 'jmp %cs:label'

I'm pretty sure I don't either. :)

the error is: error: unknown use of instruction mnemonic without a size suffix, intel/kdi/kdi_asm.S:648 jmp %cs:dbgtrap

or this: i86pc/ml/mpcore.S:108:2: error: instruction requires: 64-bit mode

I believe the kdi error is because of the superfluous %cs prefix

and clang is probably wrong about not just ignoring it.

yep, it does build it without

I'm not certain though.

intel/ml/copy.S:1139:4: error: invalid instruction mnemonic 'sstoq'

intel/ml/ddi_i86_asm.S:43:7: error: invalid operand for instruction: inb (%dx)

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)

yeah, that's not these places.

(something that might be nice to fix in it's own ticket)

unfortunately the copy.S one hits instructions dis also doesn't support.

stosq probably should just be stos, and clang doesn't like a q suffix

I have no idea what's up with inb (%dx)

same was for outb.

perhaps it wants it spelled in (%dx),%al like objdump disassembles it?

hm. good point.

you'd definitely want to test the heck out of all this and check disassemblies

yep. both mdb ::dis and objdump;)

we should probably figure out what dis hates about copy.o

lemme see if I can pin that down and file a bug while I remember.

770: 60 (bad)

seems like it's just busted.

oh, there's data in there

wowee

[illumos-gate] 15460 elfcap.chk should refer to the right symbols -- Richard Lowe <richlowe⊙rn>

sorry this made life harder on you tsoome, but it looks like it's going to make us better, too?

that was not your doing :D

it was all there...

it looks like on FreeBSD they explicitly give inb a destination

always.

all, 12 times or so they use it...

yes, just tested it, inb (%dx), %al makes it happy

there's one 'inb <immediate>' in loader

(freebsd)

richlowe: If dis is missing something, can you file a bug for me and I clean it up?

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

which picks up again, perhaps dubiously.

moving that data to be data would be good, but I very much don't want to mess with hand-optimized bcopy

does anyone of a fine vintage know if there are reasons which(1) being csh actually has compatibility implications?

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.

alanc: ^

lrwxrwxrwx 1 root root 16 Oct 17 2018 /usr/bin/which -> ../gnu/bin/which*

wow, even sufficiently fine to just use the GNU one

I believe which was csh because it was developed for csh users originally, since sh/ksh/etc. had type/whence/etc.

thanks

we switched to gnu which for 11.4

I assume we'd switch to a BSD one, for reasons, but that's certainly a relief

in that I don't have to learn of any csh-y quirks that might matter.

or bribe danmcd

Huh what?

danmcd: you're the only t?csh user I remember.

Ah.

I still like tsoome_'s idea of replacing csh in gate with tcsh, FWIW.

I prefer removing it and letting distributions ship tcsh, but yes.

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

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

I would not put tcsh in gate, but distributions could switch it out or provide a mediated package

yeah, I'm with andy.

and we could mediate it right now.

(and we can replace which(1) right now, orthogonally)

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

but those plans are all ripped up and thrown away now

There are chunks of that happening here

but because I'm lazy.

if that makes you feel better

heh, for us, it was being lazy on an instutitonal scale, and trying to avoid any work on those areas

and we had no plan to remove sun4v (just sun4u here) , so you're ahead of us in the forced retirement department

I'd love to rip out UFS and other Y2038-unsafe things. But I'm apparently slave to whatever the #%*& glibc does.

Okay, that's a bit strong, but glibc's approach to Y2038 might be worth it.

the "large time" approach is good, because we're probably stuck with 32bit x86 forever.

(to be kind to users)

but there's a lot of things on the list that are both difficult, and not worth the effort of, making 64bit clean.

at some point I'm going to write up what would be on the chopping block

How many of our users, at this point, aren't either just using pkgsrc, omnios-extra, or OI's extras?

but it's so long-term, that there's no rush for me to write it up, really.

All of those are, AFAICT, doing 64-bit. (or can w/o pain.)

I mean, that's very much a distro thing, so that's on y'all :)

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"

i386 is still limping along on FreeBSD and still has users

about to die there too.

i't mostly for libs and some applications just not getting 64bit properly going.

just about the only platform I know that is still creating i386 kernel and userland

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"

because except omnios, who I presume don't want to maintain an LTS for years and years, nobody does that here

I think it's more likely people will miss something we don't bother to port to 64bit, than they miss actually being 32bit.

if that makes sense? words are bad.

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

jclulow has fixed that for us

and I think we only use a UFS boot archive as a last resort now.

(well that, and the fact we only publish "dot-dot" micro releases now, and removing UFS in a micro release doesn't feel right)

Yeah we're using a ZFS ramdisk

Oooh, I'm going to need to bring that over jclulow

I should probably get the rest of that upstream

but as illumos has no releases, you don't have that problem - no illusion of release taxonomy to maintain

cpio for boot archive:)

just a general sense of empathy.

both better, and worse, than release taxonomy.

Yeah I think it's true we don't have releases like Solaris had

But we try to manage the same kinds of removals and additions anyway

While organising with distributors who themselves have releases and schedules

danmcd: There are some remaining design issues to nail down to make it something that will work for SmartOS

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.

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

if you look at arm64-gate, you'll even find a list of things not done, for reasons.

In the SmartOS case I expect that module could be as simple as "look at the multiboot modules to find the right one"

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.

(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)

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

For SmartOS you'll want something multibooty

Of course. And yes I'll def. want something multiboot2-y.

not half-assed, but two-assed.

lol