[lldb-dev] debug server help

Greg Clayton gclayton at apple.com
Tue Sep 18 10:17:16 PDT 2012


On Sep 18, 2012, at 3:58 AM, Carlo Kok <ck at remobjects.com> wrote:

> 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


Yikes! Malformed memory read packets. Seem like MSVC doesn't support the the 'z' modifier for printf format strings. You will need to find all format strings that contain:

%z

The 'z' specifies the size of the same size as 'size_t', so to print a size_t value as hex we often use "%zx". On windows this is just printing "zx" to the output as we can see above in the malformed memory read packets (the "zx" should be a hex size in bytes with no hex prefix). 

So find all "%zu" and "%zx" formats and replace them with "%llu" and "%llx" and cast the corresponding argument to (uint64_t).

The packets that are sent use a subclass of "Stream" called "StringStream" and we use a lot of "%zx" and "%zu" when making the GDB remote packets.

Greg Clayton




More information about the lldb-dev mailing list