Re: Debugging ld.so in gdb

[Florian Weimer <fweimer@redhat.com>]

* 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?

  disassemble *(void**)$rsp

could also be interesting.

Thanks,
Florian