10:13:25 <tsoome> 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;)
12:49:05 <andyf> I can think of other noises than whee...!
12:56:37 <andyf> Any idea where it's going wrong? The array should have 28 elements for amd64
13:12:53 <andyf> 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.
13:14:59 <tsoome> this one is 32-bit compile
13:17:12 <tsoome> 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.
13:25:25 <tsoome> and well... maybe we should not provide 32-bit libproc at all;)
13:25:56 <andyf> I haven't checked, but does it already refuse to open a 64-bit target?
13:34:53 <tsoome> at least pldd does: pldd: cannot examine 17310: program is _LP64, self is not
13:35:54 <andyf> which is coming from libproc, great.
14:22:02 <Guest38> why sh(1) manpage is the same of ksh93 if sh != ksh in illumos??
14:23:22 <Guest38> is bourne shell being deprecated in favor of ksh?
14:24:17 <andyf> On illumos, sh and ksh are the same. The older sh is available under /usr/has/bin/sh
14:25:10 <andyf> 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.
14:26:50 <Guest38> but /usr/has/bin/sh will be deprecated?
14:26:57 <andyf> and on some illumos distributions, I think that /bin/sh is replaced with something else, so experience may vary.
14:28:05 <andyf> it is deprecated as far as I know. I don't expect that directory is usually in people's PATH.
14:28:32 <Guest38> what 'has' means?
14:29:25 <andyf> I have always assumed that 'has/bin' is a play on the phrase 'has-been' - as in 'something out of date or past use.'
14:29:39 <andyf> but I have never actually asked :)
16:15:34 <sjorge> danmcd: https://gist.github.com/sjorge/ad9cc5ed97a00ceb076f2ae346d37832
16:15:45 <sjorge> i run that every reboot on mine
16:16:11 <sjorge> twitter was not letting me reply.
16:29:56 <gitomat> [illumos-gate] 14489 bhyve should emulate imul -- Andy Fiddaman <illumos⊙fn>
16:31:42 <andyf> ^ for distro maintainers, this was the last piece for persistent UEFI variables with bhyve
16:32:15 <andyf> (at least using edkII, as we all are as far as I know)
16:37:50 <sjorge> that has been in omnios for a while right?
16:39:31 <andyf> Yes, a couple of releases at least
16:40:27 <andyf> 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.
16:51:19 <sjorge> it's not ready yet to run the OMVF builds yet firmware right?
16:51:53 <andyf> I don't think anyone is doing work towards that for c-bhyve in gate
16:52:29 <sjorge> i think there are some
16:52:42 <sjorge> patches on freebsds phabricator at least
16:52:59 <sjorge> but not been tracking that super closely
16:53:02 <andyf> 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.
16:54:47 <sjorge> I don't think its merged yet, IIRC its tied up in some dynamic ACPI and Qemu compat changes to talk to the fw
16:55:10 <andyf> The dynamic ACPI stuff will be nice, and the fwcfg interface
17:10:31 <sjorge> fwcfg that was the keyword i couldnt come up with 😅