Re: Debugging ld.so in gdb

* Jacob Kroon:

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

I wonder where 0x7fffffffd2c8 is located.  Maybe on the minimal malloc
heap?

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

I think you have to enter “up” a couple of times.

I suspect we are writing beyond the start of the array passed to
_dl_sort_maps.

Thanks,
Florian