[lldb-dev] debug server help

[Carlo Kok]

Op 17-9-2012 19:31, Greg Clayton schreef:

>>
>>
>> Cool, that worked, got it starting, continuing, and fininsh now.
>> Only can't get it to break. It doesn't resolve the address of _main
>> or main, even though at this point the a.out is loaded on both the
>> server and client, I stepped through it,
>
> Does this have anything to do with the windows paths?
> "\\path\\a.out"? See comments below.

the path on the "caller" does not exactly match the "server" no (can't 
really; windows is quite different). Any way to make that work? (I know 
what local path will match the server path)

>
>>
>> when setting the BP, inside: size_t ObjectFileMachO::ParseSymtab
>> (bool minimize)
>>
>> "process" is null so it never seems to find any symbols.
>
> ObjectFile subclasses usually read their contents from disk, not from
> a process. If there is no file on disk, then LLDB will make a memory
> based ObjectFile that reads its data from memory, then the m_process
> will be valid. So the process is only needed if you are reading your
> object file from memory. Unless you have a complete local copy of
> your remote Mac system, you will end up with a lot of these, but I am
> guessing you have at least a local copy of your main executable
> "\path\a.out" right? One problem you might run into as well is all
> the paths in the DWARF debug info will use the "/path/a.out" style
> paths. I am not sure how much of this file system path stuff was
> modified in the windows port, but it will be essential to get this
> done right, so no matter what kind of path is supplied, that things
> "just work".

my DWARF files will have Windows paths (as that's where I compile from).

>>
>> Using this:
>>
>> m_debugger = SBDebugger::Create(false);
>>
>> m_target = m_debugger.CreateTarget ("\\path\\a.out",
>> "x86_64-apple-macosx", NULL, true, m_error);
>
> Now that you have a target, you will want to verify that things
> actually got loaded and that LLDB was able to parse your object file
> "\path\a.out". Try this code just after the above line that creates
> the m_target:
>
> SBModule module (m_target.FindModule(m_target.GetExecutable ())); if
> (module.IsValid()) { SBSymbol symbol; const uint32_t num_symbols =
> module.GetNumSymbols(); for (uint32_t i=0; i<num_symbols; ++i) {
> symbol = module.GetSymbolAtIndex (i); printf ("symbol[%u] 0x%16.16llx
> %s\n", i, symbol.GetName(),
> symbol.GetStartAddress().GetFileAddress()); } }
>
>
> After you create your target, should _should_ have a valid symbol
> table for your main executable. If you don't you will want to debug
> info the "module.GetNumSymbols();" code (which will parse the symbol
> table if it already hasn't been). You might need to debug info the
> "m_debugger.CreateTarget()" and watch it try to create a module with
> your "\\path\\a.out" and make sure it succeeds.


symbol[0] 0xffffffffffffffff /Users/ck/test.m
symbol[1] 0xffffffffffffffff 
/var/folders/f8/pr_1fjyd1rs8p8pn_2v488j00000gn/T/te
st-NhmVzr.o
symbol[2] 0x0000000100000f30 main
symbol[3] 0x0000000100000000 _mh_execute_header
symbol[4] 0x0000000100000f56 printf
symbol[5] 0xffffffffffffffff dyld_stub_binder


Indeed, it loads.

>
>>
>> m_process = m_target.ConnectRemote(SBListener(),
>> "connect://192.168.178.2:3333", NULL, m_error);
>>
>> SBBreakpoint bp = m_target.BreakpointCreateByName("_main");
>>
>> SBCommandReturnObject o; m_commandline.HandleCommand("breakpoint
>> list", o); << shows as not bound yet.
>>
>>
>> What am I missing?
>
> Don't add the underscore. The underscore is stripped as the symbols
> are added to the symbol table. If you notice, all C++ symbols start
> with "__Z..." (two underscores), when mangled names should only have
> 1 underscore. So we normalize the names for you so they are in the
> format you would expect. Again, it sounds like we just are not
> parsing your object file.

Oke.

>
> You might try having the program you run on MacOSX run to your main
> function and pause for 20 seconds while you then attach on windows.
> This will allow the process to get up and loaded and already have a
> bunch of shared libraries loaded. There might be issues with
> attaching to a process that is stopped at __dyld_start (which is what
> happens when you have debugserver debug an app: it starts the program
> stopped before it runs ANY code, so _nothing_ is loaded). If you
> attach after the shared libraries have loaded, we might be able to
> resolve symbols. Give that a try and let me know how things go.
>
> After you attach to a running program, try doing the following code:
>
> uint32_t num_modules = m_target.GetNumModules (); for (uint32_t i=0;
> i< num_modules; ++i) { module =  m_target.GetModuleAtIndex (i);
> printf ("module[%u] %s %s/%s\n", module.GetTriple(),
> module.GetPlatformFileSpec().GetDirectory(),
> module.GetPlatformFileSpec().GetFilename()); }
>
> This will show you what modules we discovered. If this list is empty,
> or just contains your original module, then we are not resolving the
> shared libraries, and this will make debugging not work. Again, you
> only expect to see if a list of actual modules if you attach to a
> process that has already been running, so do this with a program on
> the mac that ran to main and is doing a "sleep(20);", then attach
> with debugserver:


Tried the --attach thing after 20+ seconds, only gives (my windows path):

module[0] x86_64-apple-macosx 
C:\Users\Carlo\ConsoleApplication6\obj\Debug\a.out

(Dir = that, file = NULL)

Just one.

breakpoint list gives:
Current breakpoints:
1: name = 'main', locations = zu
   1.1: where = `main, address = (null)[0x0000000100000f30], unresolved, 
hit count = 0


>
> % ./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?