[lldb-dev] lldb on linux -- immediate crash upon attaching to process

[Stephen Wilson]

(Sorry about the delay -- it has been a busy week!)

On Thu, Mar 17, 2011 at 10:22:41AM -0700, Greg Clayton wrote:
> Jim Ingham would like to see us have debugserver re-use LLDB shared
> library (LLDB.framework on darwin, lldb.so on linux), and then
> debugserver would just use the native debugger plugin (ProcessMacOSX
> for darwin, ProcessLinux on linux) and avoid doing any symbol queries.
> We might need some sort of minimal mode within the LLDB to make sure
> we don't have both lldb and debugserver loading too many symbols,
> though with the way we have architected LLDB to only do lookups when
> asked, I think it would work just fine without any modifications.


I agree.  Perhaps the ultimate aim should be to ensure that debugserver
never does any symbol lookups at all (since the client will sometimes be
the only one with access to the debug info).

In the absolute worst case we could add an LLDB specific set of
callbacks that the target (i.e. Process) can request over the remote
protocol.  We could model that programmatically using a new "Environment"
class or similar passed as an argument to Process::CreateInstance that
would do the right thing depending on if we are running locally under
lldb or remotely under debugserver.   


> I might try out this approach to see if it works. If it does, this
> means everyone should get remote debugging for free, and need only
> implement a single local Process plug-in.

The only other thing I can think of immediately is that we would also
need a way to access the "target" file system state -- not just the
process state.  IOW, an interface that translates into Host I/O packets
when doing remote debugging and native FS operations otherwise.


For example, in the linux dynamic loader we use /proc/pid/auxv which is
a kernel-provided array of values.  We can pick them off the stack using
Process memory reads and writes but it is so much easier to just parse
the file contents.  There are other examples of in-kernel trace and
debugging hooks that are provided thru different virtual file system
interfaces.


Perhaps what we need here is a TargetIO class with a standard set of
virtual methods for reading and writing files.  The Process plugin could
provide a factory method that yields a reference to an instance of
TargetIO.   The default behaviour would be to return a generic instance
that just does local open/read/write calls.  The gdb-remote process
plugin would provide it's own specialization that provides an
implementation based on Host I/O packets.


Does any of the above sound sane/useful?  If so I can start looking at
that side of things.

-- 
steve