[lldb-dev] debug server help
gclayton at apple.com
Tue Sep 18 11:06:27 PDT 2012
I removed all uses of "%z" modifiers in our printf format strings in top of tree. Merge top of tree over to get the fixes:
% svn commit
Transmitting file data ............................................
Committed revision 164148.
On Sep 18, 2012, at 10:17 AM, Greg Clayton <gclayton at apple.com> wrote:
> 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:
>> < $E03#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:
> 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
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
More information about the lldb-dev