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
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
