Debugging ld.so in gdb

[Florian Weimer]

* 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