I think I would have eventually just loaded up a debugger and binary searched the codebase until I found the spot returning the error.
But yeah, I was just being lazy and dumb. I solved it within ten minutes of someone saying "why don't you just go through the binfmt_elf code?" A debugger would've probably been more tedious than reading the relevant code directly, but would've been just as effective.
But I'm not a kernel dev and it's been a very long time since I would have needed to debug the kernel; does this not actually work?
Unless the other os and debugger mentioned has an easy way to do it with a machine that's not virtualized?
Plan 9’s debugger Acid can attach to a running kernel on a remote machine and debug it.
This is a needlessly snide and inaccurate characterization.
> Plan 9’s debugger Acid can attach to a running kernel on a remote machine and debug it.
KGDB over Ethernet does the same on Linux.
I'm guessing you've never tried to write a terminal rendering program.
The hoops you hav to jump through to get vi to switch into a blank screen and then drop back and re-render your previous terminal.
Behaviour differences on some terminals when you run man and the previous output is simply cleared or the man page is printed and scrolled.
There are piles of hacks.