On Oct 5, 2010, at 3:11 AM, [email protected] 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.
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
