7 ms·
> Even the likes of gdb are rendered powerless before the might of this uber segfault. It's quite easy to debug crashes in the dynamic linker if you use a more
by an-unknown 3y ago
> Even the likes of gdb are rendered powerless before the might of this uber segfault.
It's quite easy to debug crashes in the dynamic linker if you use a more powerful debugger. For example there is a Graal based AMD64 VM [1] which can record an execution trace of the entire program run, including the dynamic linker, and then you can analyze the execution trace offline and see exactly what happened / what didn't happen or where the linker crashed and how it got there. In case you ever wondered what the kernel roughly does when loading an ELF file: look at the re-implementation in the ElfLoader class of that project.
[1] https://github.com/pekd/tracer https://github.com/pekd/tracer
- matheusmoreira 3y agoIn my case it was a static freestanding nolibc program, there was no dynamic linker or ELF interpreter. :) The shell's execve jumps directly to the entry point I provided. The execve itself was segfaulting somehow. I couldn't think of anything to do short of running this entire thing in a virtual machine and tracing the kernel itself to see which branch of the ELF loader I was ending up in.