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 <[email protected]> wrote: > > On Sep 18, 2012, at 3:58 AM, Carlo Kok <[email protected]> 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 > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
