[lldb-dev] Getting valid frames and odd plugin selection behaviour

Greg Clayton gclayton at apple.com
Tue Oct 5 10:10:01 PDT 2010


On Oct 5, 2010, at 3:11 AM, arvid.picciani at nokia.com wrote:

>> I just added a SBFrame::GetSymbol() for you. With the newly added GetSymbol you should get something valid:
> 
> thanks! That is indeed valid.
> 
>> This shouldn't be happening. If you get a crash backtrace, please send it to me along with the program and exact steps you were using.
> 
> will do! For now i hardcoded the macosx plugin, which appears to work.
> 
>> The "process.macosx" plug-in has bit rotted as we exclusively use the gdb-remote plug-in on darwin 
>> so we can sandbox the process in another process and it also helps us be ready for remote debugging.
> 
> Well, i don't see how to choose the plugin from the public API. Also per default, there is no gdb running.

There currently is no option when launching from the public API. If we were to add it, we would add a "const char *plugin_name = NULL" default parameter to the to process launch in SBTarget:

    lldb::SBProcess
    LaunchProcess (char const **argv,
                   char const **envp,
                   const char *tty,
                   uint32_t launch_flags,   // See lldb::LaunchFlags
                   bool stop_at_entry);

> 
>> So the first debugger plug-in to return true to CanDebug wins.
> 
> Can the gdb plugin read memory from the inferior, without starting it itself? Attach-on-demand? 
> Otherwise why would CanDebug return true?

We use the gdb remote protocol locally on the current machine by _spawning_ an instance of "debugserver" (our own, from the ground up, re-implementation of a gdbserver binary) and then communicating with it. So we do use it unconventionally by spawning it ourselves. So it should be ok to use this.

>> No, we are using an auto_ptr to hold onto the instance,
> 
> aah, thanks.
> 
>> Let me know if the above information helped explain why you weren't seeing what you thought you would?
> 
> Yes indeed, thanks alot. I understand now, that the unwinder is not at fault. Looks like it fails somewhere in 
> Module::ResolveSymbolContextForAddress. resolved_flags is 2.
> Gdb can print locals fine for that same binary. Will dig deeper and report back when i found something.

Again, any code examples of what is failing for you and steps to reproduce can help us figure our what is crashing.





More information about the lldb-dev mailing list