I figured part of this out (objdump is my new best friend), but I ran into another mystery. The problem I'm trying to diagnose is that the init process gets a segfault at some point as it comes up because it jumps to a totally bizarre and meaningless pc. The dynamic linker has finished settup up the executable, and /lib/libc.so.6 is doing something for a while. Eventually, it loads a value from memory, rotates it right by 17 bits, xors it against something it got out of TLS, and then jumps to the (totally wrong) address. I have no idea how this is supposed to do anything but break horribly, so I was wondering if anyone else has ever seen something like this before and knows what the heck libc is trying to do. I've verified that the this piece of code really does exist in libc (below), but unfortunately there's no debug information so I can't easily trace it to the originating C. The fact that the REX prefix (0x48) exists in there an unusually large number of times makes me confident this is actually code.
Gabe 6a383: 48 8b 05 e6 3a 2d 00 mov 0x2d3ae6(%rip),%rax # 33de70 <argp_program_version_hook+0x1a0> 6a38a: 48 c1 c8 11 ror $0x11,%rax 6a38e: 64 48 33 04 25 30 00 xor %fs:0x30,%rax 6a395: 00 00 6a397: ff d0 callq *%rax Gabe Black wrote: > Recently I've had the good fortune of discovering what a pain it is > to try to debug user level code in FS with no symbols. I'm going to > think about ways to make the process easier, and I was wondering if > there are any tricks other people know of that might help. Also, does > anyone know of a good way to use gdb on the dynamic linker binary? I > know /sbin/init is dynamically linked and I know where the linker gets > stuck in memory, but I haven't been able to get gdb to tell me anything > useful about it (/lib64/ld-linux-x86-64.so.2). For instance, I'd like to > disassemble its entry point, but gdb insists it can't read it for some > reason. The entry point according to the elf headers is 0xb10, and from > tracing m5 it appears that that's being relocated to 0x2b8ff0abfb10. I'm > sure I can get the bytes I need with, for instance, hexedit, but that's > a little too masochistic I think. > > Gabe > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
