Re: Debugging ld.so in gdb

On 2/4/22 18:04, Florian Weimer wrote:
> * Jacob Kroon:
> 
>> I couldn't see that address anywhere in the output of "show files".
>>
>> But I did "full" recording, and found a place where just stepping a
>> single instruction broke gdb interpreting the backtrace, if that is of
>> any help. This is what I do:
>>
>> 1. goto instruction 225037
>> 2. print backtrace (looks sane)
>> 3. do "disas"
>> 4. step one instruction with "stepi"
>> 5. print backtrace (looks garbled)
>> 6. do "disas"
> 
> Interesting.  Can you figure out where *rpo points right before things
> go wrong?  If the debuginfo doesn't work, this should do it:
> 
>   print (void *)$rax - 8
> 

This is what I get:

> (gdb) record goto 225037
> Go backward to insn number 225037
> #0  dfs_traversal (rpo=rpo@entry=0x7fffffffd3b0, map=0x7ffff7fad590, do_reldeps=do_reldeps@entry=0x0) at dl-sort-maps.c:175
> 175	  **rpo = map;
> (gdb) print *rpo
> $13 = (struct link_map **) 0x7fffffffd2c8
> (gdb) print (void *)$rax - 8
> $14 = (void *) 0x7fffffffd2c8



> Maybe also look at map->l_name at this point, and further up the stack,
> in dl_sort_maps, at maps and nmaps.  It looks like we run off the end of
> the array and write garbage to other areas of the process. 8-(
> 

And this:

> (gdb) print map->l_name 
> $15 = 0x7ffff7fad500 "/tmp/ramdisk/jacob-linux-master-glibc/work/x86_64-linux/icedtea7-native/2.1.3-r1.0/icedtea-2.1.3/build/openjdk.build-boot/lib/amd64/libjava.so"

I couldn't find the other variables, maybe I need to get more acquainted
 with the sourcecode here.

> This must be caused by something unusual in the object dependencies.
> 
> Thanks,
> Florian
> 

Jacob