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
