I finally wrote out the last sections of the blog post I've been working on for what feels like months now!

https://wakelift.de/2026/03/09/making-your-jitted-code-known-let-me-count-the-ways/

This is a post only tangentially about #rakulang, more about #pldev, in particular a brief look at Stack Unwinding in general, followed by descriptions of the RtlAddFunctionTable function in the WinAPI, #libunwind's pendant, the "perf map" and "JITDUMP" formats that came from linux's perf utility, and the jit reader functionality in #gdb. There's a short mention of #valgrind at the end as well for good measure.

Thanks also to @tekknolagi who has a blog with related topics (and who already covered the perf map among other things that are also in my post)

Just figured out what was causing an illumos Valgrind test failure. I was getting invalid reads/writes when functions with large locals were being called. I spent a long time digging through the Valgrind new/die stack mechanisms and then the code for creating the stack.

Then I noticed that with stack logging turned on that there was a new current_stack with id 1.

Hang on a sec, this is a monothread test and stack id 0 should be the only stack.

Some digging turned up Solaris "set_stack" that gets called from the syscall wrapper for getsetcontext with flag set to SETUSTACK. That gets called from ld.so for the main thread. That also means the main stack.

That results in a second stack registration for the main stack, with the stack range coming from Solaris rather than the one that we crafted at statup. These values are "wrong" compared to what Valgrind is expecting. Stack registration doesn't check for overlaps it just inserts the stack at the head of a list.

Some time after that there are stack writes and it's this 'new' main stack that gets used for accessibility checks. These accesses trigger false positive errors.

#ilumos #valgrind

Bah.

scalar: (skipping, prereq failed: kldstat -m mqueuefs > /dev/null 2>&1)

I need to spin up a FreeBSD 16 VM where I can load mqueuefs.

#valgrind #freebsd16

Fun Valgrind bugfixes of the week, number 2.

This time on illumos/Solaris amd64. I've been doing some testing on OmniOS and I noticed that the debug output (with the -d option) regularly contained corruption - a ctrl-b character - in long lines.

It seems like this is an old bug, git blame showing it as being present when the Solaris port was added to Valgrind back in 2015.

The issue was due to the debuglog function. This operates at a very low level - we want to be able to get debug logging very early on. Since we don't link with libc that means that we don't want it to even depend on our own heap manager. So roughly all it contains is a small 100 byte buffer on the stack, a vsprintf style function, a function to append 1 byte to the buffer and output the buffer when full and the function to write the buffer to file descriptor 2.

This last function is in inline assembler, and it is where the bug was. No registers were in the clobber list, but RDI is used to store the file descriptor, 2. Thart's STX or ctrl-b in ascii. Because RDI was modified it was changing the character in the first argument of the append to buffer function. After emptying the buffer the next character added was this corrupted ctrl-b character.

#valgrind #illumos #omnios

Fun Valgrind bugfixes of the week, number 1.

When you run 'valgrind' it's just a small wrapper binary that will exec the required tool (e.g., memcheck-amd64-netbsd). The wrapper needs to work out which CPU is required (since quite often 64bit arches also support 32bit binaries). It does that by looking at the ELF OSABI tag.

This was checking for UNIX System V or UNIX NetBSD.

However, if the executable uses GNU ifuncs the OSABI will be UNIX GNU. Since that wasn't handled it defaulted to Linux amd64. It then tried to exec memcheck-amd64-linux which resulted in a file not found error.

#valgrind #netbsd

I've done the first version of my slides for FOSDEM. Now I need to practise my speach and see how many of the slides fit in.

#valgrind #OpenBSD #NetBSD #dragonflybsd

Valgrind takes just over 24 hours to run through something in Darknet/YOLO.

Then it prompts once for every single issue it found. 7182 records:

==1747473== ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ----

- Is there a difference between uppercase and lowercase?
- I can guess what "n" and "y" means, but what is "c"? Cancel? Continue?

This is not a time to start experimenting since it took me over 24 hours to get to this stage, and I cannot find the answer in the valgrind docs. #cpp #valgrind

Overhelming! All those tools around building software. #Jenkins, #Github actions, #Valgrind, #Docker, #Docross, #Qemu, and what the heck more. But unfortunately all of them waay too complex and feature-bloated for my taste. In addition, I'm absolutely NOT a fan of #SaaS. But what's the alternative then? ...

Read more:
https://hiddenalpha.ch/slnk/id/1-x0VwNWaFCdXy6kl3

#SelfHosting #Virtualization #BuildEnv #Qemu #Container #Linux #BuildServer