05:57:26 <tsoome> andyf do you know why we get those *.o.s files in usr/src/test/bhyve-tests/tests/inst_emul ?
05:57:43 <tsoome> or pmooney ?
13:19:16 <andyf> tsoome - I don't think I've seen any .o.s files
13:19:28 <tsoome> hm, interesting...
13:19:51 <andyf> just checking some build trees
13:20:23 <andyf> https://paste.ec/paste/9rmNRCQI#cJvAmn+rBUbhjDBW0IODeKO0XVUQycP8k74bpwcgJiw
13:22:51 <tsoome> mine were created oct 3rd. well. no idea then:)
14:16:07 <pmooney> tsoome: I don't see files like that either
14:16:37 <pmooney> truth be told, it was kind of tricky to get the wildcard rules right to compile those tests properly
15:10:12 <jbk> i've not found anything obvious (but there's enough code I might have missed it) -- is there an easy way to force a mac ring to poll (for testing)?
16:01:20 <MichaelEngel> Great to see some people still use IRC :). I'm trying to cross-compile Illumos for aarch64/risc-v and have encountered a problem with the cross-build lex (following the instructions at https://github.com/n-hys/illumos-gate/wiki#building). I'm trying to cross-build on Ubuntu (20.04.4 LTS or 22.04 on x86-64). The cross "lex" crashes in l.344 in
16:01:20 <MichaelEngel> parser.y when lexing .../cross/src/geniconvtbl/itm_comp.l – the code in parser.y seems a bit suspicious?
16:01:21 <MichaelEngel> p = (CHR *)c;
16:01:21 <MichaelEngel> free(p);
16:01:22 <MichaelEngel> Did one of you encounter a similar problem? I could work around this by using the native Ubuntu byacc/flex (with a number of hacks due to different data types for yacc), but that's obviously less than ideal...
16:01:58 <MichaelEngel> Btw., is anyone working on a port to either Apple M1/M2 or Ampere Altra aarch64 systems?
16:04:23 <MichaelEngel> (not sure if a quick intro is common here for newcomers, please let me know if you're interested...)
16:18:33 <tsoome> pmooney it really does smell like artefact from some manual run of make...
16:19:15 <MichaelEngel> I thought so, too, but I did a fresh checkout of the source and tried on two different machines...
16:20:13 <tsoome> MichaelEngel I did not see the crash last time I was building it.
16:21:16 <tsoome> MichaelEngel atm not working on hw support, this whole thing needs a lot of work to get it actually usable.
16:25:07 <MichaelEngel> The port to the Allwinner D1 RISC-V/Nezha works amazingly well (but I didn't try to run large jobs on the machine)
16:25:14 <tsoome> MichaelEngel I'm seeing random crashes on qemu atm (I suspect that reading cpu freq can return bogus data on qemu)
16:25:38 <tsoome> for aarch64, that is.
16:26:06 <MichaelEngel> Right, haven't tried aarch64 so far, that was the next step. Wanted to get the cross-compile to work cleanly first :)
16:26:47 <tsoome> ah, that crash was with RISC-V? there it may get into alignment restrictions
16:30:55 <MichaelEngel> The crash was with the lex that is used to cross-build the system, so the crashing lex is a native x86-64 Linux ELF (built from Solaris sources in illumos-gate/usr/src/cross/src/lex) that is built in the cross-building process. It crashes while lexing geniconvtbl/itm_comp.l (or I completely misunderstood how the cross-compile process works, but I
16:30:55 <MichaelEngel> don't think so...)
16:33:58 <tsoome> do you have pstack core ?
16:34:30 <tsoome> err, that linux... so gdb and bt from that core
16:37:41 <MichaelEngel> Whoops, network fail.
16:38:21 <tsoome> MichaelEngel so gdb and bt from that core 
16:38:38 <MichaelEngel> Yep, have to add -g to the makefile to get useful output
16:40:13 <MichaelEngel> (gdb) run ../geniconvtbl/itm_comp.l
16:40:13 <MichaelEngel> Starting program: /home/me/Projects/solaris/illumos-gate/usr/src/cross/src/lex/lex ../geniconvtbl/itm_comp.l
16:40:14 <MichaelEngel> [Thread debugging using libthread_db enabled]
16:40:14 <MichaelEngel> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
16:40:15 <MichaelEngel> Program received signal SIGSEGV, Segmentation fault.
16:40:15 <MichaelEngel> 0x00007ffff7e1347e in __GI___libc_free (mem=0x555b5bd0) at ./malloc/malloc.c:3368
16:40:16 <MichaelEngel> 3368	./malloc/malloc.c: No such file or directory.
16:40:16 <MichaelEngel> (gdb) bt
16:40:17 <MichaelEngel> #0  0x00007ffff7e1347e in __GI___libc_free (mem=0x555b5bd0)
16:40:17 <MichaelEngel>     at ./malloc/malloc.c:3368
16:40:18 <MichaelEngel> #1  0x000055555555df29 in yylex ()
16:40:18 <MichaelEngel>     at /home/me/Projects/solaris/illumos-gate/usr/src/cross/src/lex/parser.y:344
16:40:19 <MichaelEngel> #2  0x0000555555560582 in yyparse ()
16:40:19 <MichaelEngel>     at /home/me/Projects/solaris/illumos-gate/usr/src/cross/lib/yaccpar:299
16:40:20 <tsoome> pastebin:)
16:40:27 <MichaelEngel> Argh, sorry, yep
16:41:05 <MichaelEngel> https://pastebin.com/siyGrZgz
16:42:27 <MichaelEngel> parser.y line 344 is the strange free of the pointer p that was assigned in the line before this to p = (CHR *)c; – removing the call to free results in a later crash somewhere else in the lex code...
16:44:15 <MichaelEngel> The lex file that is processed is this one – https://github.com/n-hys/illumos-gate/blob/osport/v2021.07/usr/src/cross/src/geniconvtbl/itm_comp.l
16:48:21 <tsoome> that parse.y line 344 is weird, but I do not see why it should crash... 
16:48:36 <tsoome> that is, it does allocate memory and free it....
16:49:27 <tsoome> myalloc() is calloc() with little warning added.
16:50:18 <tsoome> it is possible, something else is rotten in heap.
16:51:03 <tsoome> ou
16:51:05 <tsoome> ou
16:51:06 <MichaelEngel> I think so. When commenting out the free (or the malloc...free lines), lex crashed in slength. https://pastebin.com/LgyQyqeY
16:53:43 <tsoome> c = (int)myalloc(i,1); by itself is interesting, because c is not pointer, but CHR, so this code is not 64bit safe (hope it is building 32-bit)
16:54:11 <MichaelEngel> Nope, it builds a 64 bit binary...
16:54:17 <tsoome> ;)
16:54:39 <tsoome> so, your 64-bit pointer is cut to 32-bit.
16:54:51 <MichaelEngel> ouch :)
16:54:55 <tsoome> or even less, depening on size of CHR
16:55:04 <MichaelEngel> I'll try building with -m32 first
16:55:39 <tsoome> lex in illumos is built 32-bit
16:56:28 <tsoome> hm, CHR is either char or wchar_t
16:56:54 <Reinhilde> what the h-
16:57:00 <tsoome> I did not want to see that code:D
16:57:52 <MichaelEngel> It smells a bit rotten :)
16:58:29 <tsoome> I'm not really sure why does not it crash even as 32-bit x86. optimized out maybe?
16:59:16 <MichaelEngel> Might be. I'll see if I can get the lex to compile as 32-bit binary, but I have to find the missing deb packages for the 32 bit libs first...
16:59:38 <pmooney> tsoome: that looks wrong in all sorts of ways
16:59:48 <tsoome> pmooney yep:)
16:59:48 <pmooney> good find, though
17:00:37 <pmooney> shocking that compiler updates didn't turn this into some flavor of UB weirdness
17:01:56 <MichaelEngel> Ok, of course lex needs a liby to build, so I have to build a 32 bit yacc...
17:09:35 <MichaelEngel> A 32 bit lex (built with a 32 bit liby.a) built with gcc-9 (gcc-11 was unable to find the 32 bit crt*.o files...) works. Whow.
17:09:49 <tsoome> in any case it seeme that useless myalloc + free can be dropped
17:14:52 <tsoome> for a starter, I'd suggest to build lex without all of those -W-no-* switches:D
17:18:05 <MichaelEngel> It's amazing that the lex source isn't 64 bit clean... I remember buying our first 64 bit UltraSPARC 1 in late 1995. But, of course, Solaris 2.5.1 wasn't 64 bit back then :)
17:19:00 <tsoome> large portion of userspace is 32-bit
17:19:19 <tsoome> thats the curse of having mixed 32/64 bit support.
17:20:34 <MichaelEngel> Yep, I never noticed this even though I ran Solaris for more than a decade on Sparc and x86... back to SunOS 4 where everything is nice and easy, I guess :D  (still have my trusty old 3/60 sitting in a corner)
17:21:45 <tsoome> eh...
17:24:32 <MichaelEngel> So I'm always looking for OS-related projects for my students here (Bamberg University in Germany) and working on Solaris would be a nice exercise. We have some M1/M2 aarch64 Macs here and will hopefully receive some HPE Proliant Ampere servers soon. Both would be nice platforms for Illumos, I think. By coincidence, I'm also looking for a PhD
17:24:33 <MichaelEngel> student :)
17:26:36 <gitomat> [illumos-gate] 15054 libc: using the result of an assignment as a condition without parentheses -- Toomas Soome <tsoome⊙mc>
17:30:29 <tsoome> Considering how long I did my MSc, I should not consider PhD:D
17:32:09 <MichaelEngel> Oh well, I also studied for far too many years... well, I'm still at a university 30 years later, not sure if this is progress :)
17:32:23 <tsoome> but for example the same 32 to 64 bit transitions could be nice student projects
17:32:44 <MichaelEngel> But we had lots of fun with all sorts of crazy Unix machines in the '90s, you could learn so much.
17:35:04 <MichaelEngel> The 32/64 bit bugs might also be a good starting point to introduce the students to tools for static code analysis.
17:35:08 <tsoome> I was in uni for quite some time, but eventually had to start to earn some... :)
17:37:40 <MichaelEngel> OK, now there's a strange yacc-related error when building dtrace, but that will have to wait until tomorrow. Need to finish my lecture slides for tomorrow :)
17:37:48 <MichaelEngel> Thanks a lot for all your help!
17:39:56 <tsoome> yw. what lecture it would be?:)
17:41:17 <MichaelEngel> This semester it's a course on virtualization, tomorrow's lecture is on CPU emulation from interpreter to static/dynamic binary translation. The course covers all levels of virtualization from CPU (e.g. Transmeta) over system level to high-level VMs (e.g. for Java or Webassembly).
17:41:33 <tsoome> I see.
17:43:29 <gitomat> [illumos-gate] 15005 Tests for btree implementation used by range trees -- John Wren Kennedy <john.kennedy⊙dc>
17:48:46 <MichaelEngel> We have an OS engineering course in the summer term where students build their own little preemptive multitasking RISC-V OS from scratch. This is also a lot of fun.
17:49:34 <tsoome> nice
17:53:04 <gitomat> [illumos-gate] 15093 SMB error after Win10 tries FSCTL_PIPE_WAIT -- Gordon Ross <gwr⊙rc>
17:54:08 <toasterson> MichaelEngel: M1/M2 and Ampere are two different beasts. The built bootfiles I made for Qemu run on Ampere if you can find a passable bootloader or get loader compiled for UEFI mode on aarch64
17:55:17 <toasterson> As for the M1 you will need a custom bootloader chain to conform to apple boot I think the Asahi Linux installer creates a chain that is UEFI compatible and then you can chain to loader but if not you will need to make a custom bootloader for the M1
17:57:02 <MichaelEngel> toasterson: yes, I know they are quite a bit different – more work for my students :). I'll try the Ampere stuff as soon as I receive the hardware, for the M1 I will check out the OpenBSD code (7.2 supports all M1/M2 models), though I think they also rely on the Asahi Linux bootloader.
17:57:06 <richlowe> yeah, lex isn't clean, and also isn't _clean_
18:00:53 <MichaelEngel> I assume the Illumos lex is derived from the old SVR4 version and not (closely) related to bison or Berkeley yacc?
18:01:18 <richlowe> it's not related to flex, it might be related to berkeley lex
18:01:22 <richlowe> but I don't know
18:01:28 <richlowe> it certainly has the structure of something from new jersey
18:03:49 <richlowe> if you're not wanting to fix it for fun, you might want to wait until the native cross-build works?
18:03:55 <richlowe> what a weird sentence
18:04:00 <richlowe> "the cross-build from another illumos platform"
18:04:31 <MichaelEngel> Modifying the makefiles to build yacc and lex as 32 bit seems to be a workaround that's good enough for now.
18:04:54 <richlowe> well, I missed what your goal is, to be honest.
18:05:14 <richlowe> but a "proper" illumos build of aarch64 is something very much actively work in progress right now among some folks
18:05:34 <MichaelEngel> Another bug that showed up is that a SIGSTKSZ was included in a list of signals by accident, this patch fixes it. https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=39d53d04357606a15efd400147fa7369d71baf2c;hp=46039d3632e32d9a404c1f18cf55f14c894e4627
18:06:09 <MichaelEngel> Yeah, I read that the native linker seems to be a roadblock right now?
18:06:27 <richlowe> The port of that is probably 95% complete.
18:07:59 <richlowe> I haven't implemented thread-local storage just yet, because only a couple of things need it and they're not themselves needed just yet
18:08:09 <richlowe> the _major_ pain in the ass is libm
18:27:04 <jclulow> maths is hard
18:56:39 <richlowe> I don't know if it's hard, or I'm bad at it, but yes.
18:56:43 <richlowe> the code is also very bad.
18:56:50 <richlowe> and the only quad code we have is big endian
18:56:56 <richlowe> and also... uh, optimized circa the 90s
18:57:43 <richlowe> so it's a mix of math I can't do myself, implemented confusingly
18:58:34 <richlowe> but things are going pretty well toward a target of "being illumos-y" so people can help
19:00:04 <richlowe> and it's keeping me away from debating whether modifying compilers is a priori a bad thing
19:00:08 <richlowe> so that's a great feature
20:09:42 <gitomat> [illumos-gate] 15068 diskinfo crash in nvlist_free() -- Andy Fiddaman <illumos⊙fn>
20:12:10 <toasterson> richlowe: I can debate that for you :)
20:14:03 <toasterson> On another topic. Can somebody give me some instructions on disassembling the instruction that generated the trap for #15088 !fenix
20:14:04 <fenix> BUG 15088: Kernel panic in TUN device unvailable when mounting NFS share over tailscale TUN network (New)
20:14:04 <fenix> ↳ https://www.illumos.org/issues/15088
20:14:44 <richlowe> <address>/i or ::dis
20:15:32 <richlowe> so tun_frame+211/i will give you just that instruction, or you could disassemble all of tun_frame with tun_frame::dis and get some context
20:15:58 <toasterson> so open the core with mdb -> fffffe000f13aa60/i ?
20:16:33 <richlowe> no, that's the stack frame
20:16:43 <richlowe> literally 'tun_frame+211/i'
20:17:14 <toasterson> so that give something like `tun_frame+0x211:movdqa (%rsi),%xmm0`
20:17:35 <toasterson> is that what would help? Or you think some more would be nice?
20:17:57 <richlowe> I'd dissassemble the whole function, but if it's actually using SSE like that implies that's definitely going to go wrong
20:18:20 <richlowe> but hopefully I spaced on something and gave you bad info
20:18:57 <richlowe> but it does look like it's using SSE and probably got built with -mno-sse etc, etc, etc.
20:19:05 <richlowe> see STAND_FLAGS in usr/src/Makefile.master
20:19:27 <richlowe> built _without_ -mno-sse etc
20:21:49 <richlowe> (I'm not saying that's why it's crashing, but it's certainly pretty suspicious)
20:21:50 <toasterson> Ok, added the info. Thanks for the tutorial :)
20:24:28 <andyf> The options that omnios uses for building it are here, if that helps: https://github.com/citrus-it/omnios-build/blob/master/build/tuntap/build.sh#L32
20:28:49 <toasterson> oh, right thats a userland module........ brb
20:29:16 <toasterson> also if you type exit in mdb it shows me the dissasembled output XD
20:29:39 <richlowe> $q quits (if you're in kmdb, it may also reboot)
20:29:59 <richlowe> if you type an address like 'exit', without a command, it runs the last command on the new address
20:30:05 <richlowe> a great and exciting way to absolutely hose yourself by mistake :)
20:33:12 <toasterson> thankfully I was in a core :)
20:57:06 <toasterson> hmmm `'-mindirect-branch=thunk-extern' and '-mcmodel=large' are not compatible`
20:57:35 <toasterson> mcmodel should be kernel no?
20:59:05 <toasterson> hmmm it gets set somewhere....
21:00:08 <toasterson> ah, i also need patches...
21:04:40 <toasterson> andyf: from where are you getting your tuntap package sources from?
21:05:38 <toasterson> we get ours from github.com/kaizawa/tuntap
21:05:41 <richlowe> -mcmodel=kernel for the kernel on i86 yes
21:06:20 <richlowe> your flags should be exactly what you see from STAND_FLAGS (in Makefile.master), and the addenda in Makefile.uts 
21:06:28 <andyf> It will be from https://mirrors.omnios.org/tuntap/
21:06:31 <richlowe> or you're going to have weirdness
21:17:16 <toasterson> richlowe: is `-Wu,-save_args` gcc related?
21:17:40 <richlowe> it's Sun Studio option, cw translates it to -msave-args
21:20:24 <toasterson> ok, so `-msave-args` is also needed for illumos-gate
21:54:38 <toasterson> ok, so far stable with the right CFLAGS
21:54:49 <toasterson> thanks for the pointers
23:53:56 <gitomat> [illumos-gate] 15118 bhyve too strict over vmm_data lengths -- Patrick Mooney <pmooney⊙pc>