[lldb-dev] debug server help

[Greg Clayton]

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
Sending        source/API/SBBreakpoint.cpp
Sending        source/API/SBCommunication.cpp
Sending        source/API/SBDebugger.cpp
Sending        source/API/SBFileSpec.cpp
Sending        source/API/SBProcess.cpp
Sending        source/API/SBValue.cpp
Sending        source/Breakpoint/Breakpoint.cpp
Sending        source/Breakpoint/BreakpointLocationList.cpp
Sending        source/Breakpoint/WatchpointList.cpp
Sending        source/Commands/CommandObjectMemory.cpp
Sending        source/Core/Communication.cpp
Sending        source/Core/ConnectionFileDescriptor.cpp
Sending        source/Core/ConstString.cpp
Sending        source/Core/EmulateInstruction.cpp
Sending        source/Core/Module.cpp
Sending        source/Expression/ClangFunction.cpp
Sending        source/Expression/DWARFExpression.cpp
Sending        source/Host/macosx/Host.mm
Sending        source/Interpreter/Args.cpp
Sending        source/Interpreter/OptionValueArray.cpp
Sending        source/Plugins/Process/MacOSX-Kernel/CommunicationKDP.cpp
Sending        source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
Sending        source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
Sending        source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
Sending        source/Plugins/SymbolFile/DWARF/DWARFDebugAranges.cpp
Sending        source/Plugins/SymbolFile/DWARF/DWARFDebugPubnames.cpp
Sending        source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
Sending        source/Plugins/UnwindAssembly/InstEmulation/UnwindAssemblyInstEmulation.cpp
Sending        source/Symbol/ClangASTContext.cpp
Sending        source/Target/Memory.cpp
Sending        source/Target/Process.cpp
Sending        source/Target/Target.cpp
Sending        source/Target/ThreadList.cpp
Sending        tools/debugserver/source/DNB.cpp
Sending        tools/debugserver/source/DNBBreakpoint.cpp
Sending        tools/debugserver/source/MacOSX/MachException.cpp
Sending        tools/debugserver/source/MacOSX/MachProcess.cpp
Sending        tools/debugserver/source/MacOSX/MachTask.cpp
Sending        tools/debugserver/source/MacOSX/arm/DNBArchImpl.cpp
Sending        tools/debugserver/source/MacOSX/i386/DNBArchImplI386.cpp
Sending        tools/debugserver/source/MacOSX/x86_64/DNBArchImplX86_64.cpp
Sending        tools/debugserver/source/RNBRemote.cpp
Sending        tools/debugserver/source/RNBSocket.cpp
Sending        tools/debugserver/source/debugserver.cpp
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:
>> 
>>> $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
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev