Re: Debugging ld.so in gdb
Florian Weimer via Gdb <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <[email protected]> |
* Jacob Kroon: > On 2/4/22 15:22, Florian Weimer wrote: >> * Jacob Kroon: >> >>> This is what I get, following the instructions above: >>> >>>> 171966 0x00007ffff7fd85a0 <dfs_traversal+80>: mov 0x0(%r13),%rax >>>> 171967 0x00007ffff7fd85a4 <dfs_traversal+84>: lea -0x8(%rax),%rdx >>>> 171968 0x00007ffff7fd85a8 <dfs_traversal+88>: mov %rdx,0x0(%r13) >>>> 171969 0x00007ffff7fd85ac <dfs_traversal+92>: mov %rbp,-0x8(%rax) >>>> 171970 0x00007ffff7fd85b0 <dfs_traversal+96>: add $0x8,%rsp >>>> 171971 0x00007ffff7fd85b4 <dfs_traversal+100>: pop %rbx >>>> 171972 0x00007ffff7fd85b5 <dfs_traversal+101>: pop %rbp >>>> 171973 0x00007ffff7fd85b6 <dfs_traversal+102>: pop %r12 >>>> 171974 0x00007ffff7fd85b8 <dfs_traversal+104>: pop %r13 >>>> 171975 0x00007ffff7fd85ba <dfs_traversal+106>: ret >>> >>> Does that make sense ? Any other information I can provide. This is with >>> glibc-2.34-24.fc35.x86_64, Fedora 35. >> >> This doesn't really make sense. There's probably some GDB option to get >> a longer trace. >> >> If it is crashing at the RET, it means that either code has been mapped >> over, or the stack has been corrupted. At the crash site, what does >> >> print *(void**)$rsp >> >> print? >> > > $2 = (void *) 0x7ffff7d31b70 > >> disassemble *(void**)$rsp >> >> could also be interesting. >> > > "No function contains specified address" > > Let me see if I can find some gdb option to get a longer trace. Looks like the code at that address has been unmapped (or the link map is at least gone from a GDB perspective). Maybe you can see what was at the address before using “info files”? Thanks, Florian