Debugging ld.so in gdb

[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.

Jacob