[Lldb-commits] [PATCH][RFC] Linux DynamicLoader plugin.

Greg Clayton gclayton at apple.com
Sun Jan 16 18:02:07 PST 2011


On Jan 16, 2011, at 12:25 PM, Stephen Wilson wrote:

> Greg Clayton <gclayton at apple.com> writes:
>> Looks good, and great news that linux now has a dynamic loader.
> 
> Committed in r123592.
> 
>> The nice thing is if you want remote linux debugging, we can modify
>> the ProcessGDBRemote plug-in, on linux by default, to use this dynamic
>> loader plug-in since they are completely pluggable. We would need to
>> just write a linux remote debug server. The current "debugserver"
>> project really needs to be re-written from the ground up using the
>> classes we have in LLDB (StringExtractor, GDBRemoteCommunication,
>> StringExtractorGDBRemote).
> 
> Out of curiosity, would you be OK with a debug server written in plain
> C?  Main reason is that on many embedded systems a C++ runtime is not
> available.  I do not have any plans at the moment to work on it, I am
> just curious if such an effort could be folded into LLDB proper instead
> of being an independent project.

Anyone else is welcome to do this, but on darwin, we won't be doing this. Why? We want to be sure to share the debugging backend for both the native and remote debugging. Right now we have disabled the native debugging plug-in for MacOSX and we debug remotely even when debugging local processes. We do this by spawning a debugserver instance and attach to a known port number (passed in via a command line option) and then have the debugserver launch the inferior process. Partly to insulate lldb from bad things happening to parent processes when debugging a child process, and partly so we are just ready for remote debugging. Soon we plan to re-enable the native debugging plug-in, but we plan to switch over to using the DNB.h interface that we use inside debugserver for local debugging. Previously we were maintaining both a copy of the debugging backend in both debugserver and in ProcessMacOSX which was a bit tedious and sometimes we would fix something in one and not the other. 

BTW: the interface in DNB.h is a nice concise C level debugging interface that could be used for the simpler GDB remote server. If the GDB remote server was written in C, then each new debug target could just implement their own implementation of the DNB.h interface and have it both work for native and remote debugging. The interface in DNB.h is designed to be dynamic to allow for self describing registers and register sets, and much more.

>> One might also be able to make slight modifications to the existing
>> GDB gdbserver binary (from the current GDB sources) for linux, and use
>> it as the remote stub to connect to with LLDB!
> 
> That is an interesting option.  Will keep it in mind.
> 
> 
> Take care,
> 
> --
> steve





More information about the lldb-commits mailing list