[lldb-dev] debug server help

[Carlo Kok]

Op 17-9-2012 23:23, Greg Clayton schreef:
>>
>>
>> breakpoint list gives:
>> Current breakpoints:
>> 1: name = 'main', locations = zu
>>   1.1: where = `main, address = (null)[0x0000000100000f30], unresolved, hit count = 0
>
> Yep, so we have a breakpoint we just aren't getting shared libraries to load. See below.
>>
>>>
>>> % ./a.out ... (a.out is sleeping in main) % /path/to/debugserver
>>> localhost:3333 --attach <pid>
>>
>>
>> It's like the server side never tells about the modules. Any place I can debug and step into to narrow this down?
>
> DYLD is having trouble syncing up and figuring itself out and where stuff lives in it.
>
> You will need to debug through "DynamicLoaderMacOSXDYLD::LocateDYLD()" and let me know what path it is taking and how it is failing.
>
> The basics of what this function will try to do:
> 1 - it will use a hint address given to us by "debugserver" to locate an important data structure in /usr/lib/dylb
> 2 - it will try and figure out the base address of dyld in memory
> 	I would expect this to work and I would expect us to execute and succeed with a call to DynamicLoaderMacOSXDYLD.cpp:257:
>                   return ReadDYLDInfoFromMemoryAndSetNotificationCallback (m_dyld_all_image_infos.dyldImageLoadAddress);
> 3 - all image infos will be loaded in the above command. Debug it and let me know what is failing
>
> Greg Clayton
>

With --attach:

shlib_addr = 0x00007fff654c1b80

if (m_process->ReadMemory (shlib_addr, buf, 4, error) == 4) << fails

Inside ReadAllImageInfosStructure the m_dyld_all_image_infos_addr ends 
up as 0x00007fff654c1b80 and also fails loading.

the relevant part of the socket transcript:

 > $qShlibInfoAddr#00
 > $7fff654c1b80#00
 > $m7fff654c1a00,zx#00
< $E03#00
 > $m7fff654c1a00,zx#00
< $E03#00