andyf do you know why we get those *.o.s files in usr/src/test/bhyve-tests/tests/inst_emul ?

or pmooney ?

tsoome - I don't think I've seen any .o.s files

hm, interesting...

just checking some build trees

mine were created oct 3rd. well. no idea then:)

tsoome: I don't see files like that either

truth be told, it was kind of tricky to get the wildcard rules right to compile those tests properly

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

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

parser.y when lexing .../cross/src/geniconvtbl/itm_comp.l – the code in parser.y seems a bit suspicious?

p = (CHR *)c;

free(p);

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

Btw., is anyone working on a port to either Apple M1/M2 or Ampere Altra aarch64 systems?

(not sure if a quick intro is common here for newcomers, please let me know if you're interested...)

pmooney it really does smell like artefact from some manual run of make...

I thought so, too, but I did a fresh checkout of the source and tried on two different machines...

MichaelEngel I did not see the crash last time I was building it.

MichaelEngel atm not working on hw support, this whole thing needs a lot of work to get it actually usable.

The port to the Allwinner D1 RISC-V/Nezha works amazingly well (but I didn't try to run large jobs on the machine)

MichaelEngel I'm seeing random crashes on qemu atm (I suspect that reading cpu freq can return bogus data on qemu)

for aarch64, that is.

Right, haven't tried aarch64 so far, that was the next step. Wanted to get the cross-compile to work cleanly first :)

ah, that crash was with RISC-V? there it may get into alignment restrictions

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

don't think so...)

do you have pstack core ?

err, that linux... so gdb and bt from that core

Whoops, network fail.

MichaelEngel so gdb and bt from that core

Yep, have to add -g to the makefile to get useful output

(gdb) run ../geniconvtbl/itm_comp.l

Starting program: /home/me/Projects/solaris/illumos-gate/usr/src/cross/src/lex/lex ../geniconvtbl/itm_comp.l

[Thread debugging using libthread_db enabled]

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.

0x00007ffff7e1347e in __GI___libc_free (mem=0x555b5bd0) at ./malloc/malloc.c:3368

3368 ./malloc/malloc.c: No such file or directory.

(gdb) bt

#0 0x00007ffff7e1347e in __GI___libc_free (mem=0x555b5bd0)

    at ./malloc/malloc.c:3368

#1 0x000055555555df29 in yylex ()

    at /home/me/Projects/solaris/illumos-gate/usr/src/cross/src/lex/parser.y:344

#2 0x0000555555560582 in yyparse ()

    at /home/me/Projects/solaris/illumos-gate/usr/src/cross/lib/yaccpar:299

pastebin:)

Argh, sorry, yep

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

The lex file that is processed is this one – github.com/n-hys/illumos-gate/blob/…rc/cross/src/geniconvtbl/itm_comp.l

that parse.y line 344 is weird, but I do not see why it should crash...

that is, it does allocate memory and free it....

myalloc() is calloc() with little warning added.

it is possible, something else is rotten in heap.

ou

ou

I think so. When commenting out the free (or the malloc...free lines), lex crashed in slength. pastebin.com/LgyQyqeY

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)

Nope, it builds a 64 bit binary...

;)

so, your 64-bit pointer is cut to 32-bit.

ouch :)

or even less, depening on size of CHR

I'll try building with -m32 first

lex in illumos is built 32-bit

hm, CHR is either char or wchar_t

what the h-

I did not want to see that code:D

It smells a bit rotten :)

I'm not really sure why does not it crash even as 32-bit x86. optimized out maybe?

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

tsoome: that looks wrong in all sorts of ways

pmooney yep:)

good find, though

shocking that compiler updates didn't turn this into some flavor of UB weirdness

Ok, of course lex needs a liby to build, so I have to build a 32 bit yacc...

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.

in any case it seeme that useless myalloc + free can be dropped

for a starter, I'd suggest to build lex without all of those -W-no-* switches:D

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

large portion of userspace is 32-bit

thats the curse of having mixed 32/64 bit support.

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)

eh...

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

student :)

[illumos-gate] 15054 libc: using the result of an assignment as a condition without parentheses -- Toomas Soome <tsoome⊙mc>

Considering how long I did my MSc, I should not consider PhD:D

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

but for example the same 32 to 64 bit transitions could be nice student projects

But we had lots of fun with all sorts of crazy Unix machines in the '90s, you could learn so much.

The 32/64 bit bugs might also be a good starting point to introduce the students to tools for static code analysis.

I was in uni for quite some time, but eventually had to start to earn some... :)

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

Thanks a lot for all your help!

yw. what lecture it would be?:)

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

I see.

[illumos-gate] 15005 Tests for btree implementation used by range trees -- John Wren Kennedy <john.kennedy⊙dc>

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.

nice

[illumos-gate] 15093 SMB error after Win10 tries FSCTL_PIPE_WAIT -- Gordon Ross <gwr⊙rc>

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

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

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.

yeah, lex isn't clean, and also isn't _clean_

I assume the Illumos lex is derived from the old SVR4 version and not (closely) related to bison or Berkeley yacc?

it's not related to flex, it might be related to berkeley lex

but I don't know

it certainly has the structure of something from new jersey

if you're not wanting to fix it for fun, you might want to wait until the native cross-build works?

what a weird sentence

"the cross-build from another illumos platform"

Modifying the makefiles to build yacc and lex as 32 bit seems to be a workaround that's good enough for now.

well, I missed what your goal is, to be honest.

but a "proper" illumos build of aarch64 is something very much actively work in progress right now among some folks

Another bug that showed up is that a SIGSTKSZ was included in a list of signals by accident, this patch fixes it. sourceware.org/git/?p=binutils-gdb.…d3632e32d9a404c1f18cf55f14c894e4627

Yeah, I read that the native linker seems to be a roadblock right now?

The port of that is probably 95% complete.

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

the _major_ pain in the ass is libm

maths is hard

I don't know if it's hard, or I'm bad at it, but yes.

the code is also very bad.

and the only quad code we have is big endian

and also... uh, optimized circa the 90s

so it's a mix of math I can't do myself, implemented confusingly

but things are going pretty well toward a target of "being illumos-y" so people can help

and it's keeping me away from debating whether modifying compilers is a priori a bad thing

so that's a great feature

[illumos-gate] 15068 diskinfo crash in nvlist_free() -- Andy Fiddaman <illumos⊙fn>

richlowe: I can debate that for you :)

On another topic. Can somebody give me some instructions on disassembling the instruction that generated the trap for #15088 !fenix

BUG 15088: Kernel panic in TUN device unvailable when mounting NFS share over tailscale TUN network (New)

↳ illumos.org/issues/15088

<address>/i or ::dis

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

so open the core with mdb -> fffffe000f13aa60/i ?

no, that's the stack frame

literally 'tun_frame+211/i'

so that give something like `tun_frame+0x211:movdqa (%rsi),%xmm0`

is that what would help? Or you think some more would be nice?

I'd dissassemble the whole function, but if it's actually using SSE like that implies that's definitely going to go wrong

but hopefully I spaced on something and gave you bad info

but it does look like it's using SSE and probably got built with -mno-sse etc, etc, etc.

see STAND_FLAGS in usr/src/Makefile.master

built _without_ -mno-sse etc

(I'm not saying that's why it's crashing, but it's certainly pretty suspicious)

Ok, added the info. Thanks for the tutorial :)

The options that omnios uses for building it are here, if that helps: github.com/citrus-it/omnios-build/b…ob/master/build/tuntap/build.sh#L32

oh, right thats a userland module........ brb

also if you type exit in mdb it shows me the dissasembled output XD

$q quits (if you're in kmdb, it may also reboot)

if you type an address like 'exit', without a command, it runs the last command on the new address

a great and exciting way to absolutely hose yourself by mistake :)

thankfully I was in a core :)

hmmm `'-mindirect-branch=thunk-extern' and '-mcmodel=large' are not compatible`

mcmodel should be kernel no?

hmmm it gets set somewhere....

ah, i also need patches...

andyf: from where are you getting your tuntap package sources from?

we get ours from github.com/kaizawa/tuntap

-mcmodel=kernel for the kernel on i86 yes

your flags should be exactly what you see from STAND_FLAGS (in Makefile.master), and the addenda in Makefile.uts

It will be from mirrors.omnios.org/tuntap

or you're going to have weirdness

richlowe: is `-Wu,-save_args` gcc related?

it's Sun Studio option, cw translates it to -msave-args

ok, so `-msave-args` is also needed for illumos-gate

ok, so far stable with the right CFLAGS

thanks for the pointers

[illumos-gate] 15118 bhyve too strict over vmm_data lengths -- Patrick Mooney <pmooney⊙pc>