[lldb-dev] debug server help

[Greg Clayton]

On Sep 15, 2012, at 10:58 AM, Carlo Kok <ck at remobjects.com> wrote:

> Op 14-9-2012 21:45, Greg Clayton schreef:
> 
> 
> Thanks for all the help,
> 
>>>> 
>>> 
>>> It does now, thanks... Is there something that should how to
>>> proceed from there? (from code or from lldb cmdline)? (ie what's
>>> the next step in debugging , get the process, do the first step,
>>> work with symbols?, not asking for all of them, just a starting
>>> point)
>> 
>> If you are going to be building an tool that does debugging, I would
>> suggest you compile LLDB into a dll on windwos (LLDB.dll) and work
>> through the public LLDB API (anything that starts with "lldb::SB"
>> (where SB stands for script bridge)). Is there a reasons you were
>> coding with the internal API?
> 
> I made some mistakes there, I'm using the internal apis now.

The public API's, yes. much better.

> 
>> What are you trying to do here? What is the main goal?
> 
> Trying to make a gui (Visual Studio plugin) around LLDB for our LLVM based language.

Great!

> 
> There is a good example about how to setup an event
>> loop to monitor a process you are debugging in:
>> 
>> lldb/examples/python/process_events.py
>> 
>> It is in python, but python also uses the exact same API as is
>> available.
>> 
> 
> 
> 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.

> 
> 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". 
> 
> 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.

> 
> 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.

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:

% ./a.out
... (a.out is sleeping in main)
% /path/to/debugserver localhost:3333 --attach <pid>



> 
> 
> 
> Carlo Kok
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev