whee: ../common/Pcore.c:550:2: error: array index 20 is past the end of the array (which contains 19 elements) (code line: lwp->lwp_status.pr_reg[REG_RSP] = prs64->pr_reg.lxr_rsp;)

I can think of other noises than whee...!

Any idea where it's going wrong? The array should have 28 elements for amd64

Do we generally expect the 32-bit libproc.so to be dealing with 64-bit things? Maybe the fix is just to refuse to convert the lx prstatus64 to lwp_status in the 32-bit library? The ptools isaexec anyway.

this one is 32-bit compile

and yes, it is just about quality of compiler diagnostics; the register array size is defined constant, depending on 32 or 64 bit mode and is easy to overlook by human.

and well... maybe we should not provide 32-bit libproc at all;)

I haven't checked, but does it already refuse to open a 64-bit target?

at least pldd does: pldd: cannot examine 17310: program is _LP64, self is not

which is coming from libproc, great.

why sh(1) manpage is the same of ksh93 if sh != ksh in illumos??

is bourne shell being deprecated in favor of ksh?

On illumos, sh and ksh are the same. The older sh is available under /usr/has/bin/sh

There's no guarantee it will always stay that way though, as in one shouldn't assume that /bin/sh is ksh. If you use ksh features, put /bin/ksh in the shebang.

but /usr/has/bin/sh will be deprecated?

and on some illumos distributions, I think that /bin/sh is replaced with something else, so experience may vary.

it is deprecated as far as I know. I don't expect that directory is usually in people's PATH.

what 'has' means?

I have always assumed that 'has/bin' is a play on the phrase 'has-been' - as in 'something out of date or past use.'

but I have never actually asked :)

danmcd: gist.github.com/sjorge/ad9cc5ed97a00ceb076f2ae346d37832

i run that every reboot on mine

twitter was not letting me reply.

[illumos-gate] 14489 bhyve should emulate imul -- Andy Fiddaman <illumos⊙fn>

^ for distro maintainers, this was the last piece for persistent UEFI variables with bhyve

(at least using edkII, as we all are as far as I know)

that has been in omnios for a while right?

Yes, a couple of releases at least

It just took me a while to be sure of the testing for RTI, and then pmooney helped by writing a proper "runs-in-a-guest" test case.

it's not ready yet to run the OMVF builds yet firmware right?

I don't think anyone is doing work towards that for c-bhyve in gate

i think there are some

patches on freebsds phabricator at least

but not been tracking that super closely

I'm a couple of months behind on upstream so a bit out of touch. I do plan another upstream sync at the end of the year though.

I don't think its merged yet, IIRC its tied up in some dynamic ACPI and Qemu compat changes to talk to the fw

The dynamic ACPI stuff will be nice, and the fwcfg interface

fwcfg that was the keyword i couldnt come up with 😅