Re: Debugging ld.so in gdb

On 2/7/22 13:27, Florian Weimer wrote:
> * Jacob Kroon:
> 
>>> What I find really confusing is that this is not the result of a dlopen
>>> call.  I definitely would expect that the maps array contains *all*
>>> objects that are being loaded.  Clearly this is not the case here.
>>> Somehow certain objects are missing, and then they get written into the
>>> rpo array.
>>>
>>> Please try to find libjvm.so among the l_initfini arrays of the objects.
>>
>> I do find libjvm.so in a couple of the maps[]->l_initfini[]->l_name
>> arrays, yes.
> 
> Okay, and of course there is an assumption that those make it to the
> maps.  No wonder we run off the array.
> 
>>> It must be present somewhere.  I assume it's also on the main list,
>>> which starts off at _rtld_global._dl_ns[0]._ns_loaded.
>>
>> Hmm how do I iterate over that data structure ?
>>
>> See below:
>>> (gdb) print _rtld_global._dl_ns[0]._ns_loaded[0]->l_name
>>> $186 = 0x7ffff7ff1d97 ""
>>> (gdb) print _rtld_global._dl_ns[0]._ns_loaded[1]->l_name
>>> $187 = 0x0
>>> (gdb) print _rtld_global._dl_ns[0]._ns_loaded[2]->l_name
>>> $188 = 0x0
>>> (gdb) print _rtld_global._dl_ns[0]._ns_loaded->l_name
>>> $189 = 0x7ffff7ff1d97 ""
>>> (gdb) print _rtld_global._dl_ns[1]._ns_loaded->l_name
>>> Cannot access memory at address 0x8
>>> (gdb) print _rtld_global._dl_ns[2]._ns_loaded->l_name
>>> Cannot access memory at address 0x8
> 
> It's a list chained by l_prev/l_next.
> 

Ok, yes "libjvm.so" is there, in multiple entries.

Jacob