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

[Stephen Wilson]

On Wed, Mar 16, 2011 at 10:25:49AM -0700, Greg Clayton wrote:
> 1 - Modifying DNB.h to make sure it does all we need it to for all platforms
> 2 - Grab the code from within ProcessLinux and put it in a new DNB.cpp implementation for linux
> 3 - Make the ProcessLinux code us the DNB.h interface
> 4 - Reuse DNB.cpp/.h for linux in a new or modified version of "debugserver"

At first I was into this idea.  If we can keep DNB.h C compatible then I
see lots of benefits to the transition.  I am particularly thinking
about the embedded developer here who may not have a C++ runtime but who
might like a simple way to hook their tools into LLDB so that they can
run on their boards, workstations, emulators, etc.  Even more generally,
I think giving LLDB a window into plugins/tools that can provide a C API
is a good thing.

However, I have to admit to being a little concerned about having two
very similar API's side by side.  I am quite tempted to suggest that
when/if the current debug server gets an overhaul it be rewritten to use
the Process API and use similar idioms of "plugin resource discovery" to
provide a generic/portable implementation that does a
packet-to-process-plugin translation thing.

I do not think that would necessarily leave C programmers out in the
cold:  they would still be able to define Process plugin wrappers or
implement the gdb remote protocol.

So perhaps DNB.h might be best thought of *exclusively* as a C-level
API.  If we wanted to support such a thing, then we could provide a
standard DNBProcess wrapper that C code could link against.  Similarly
we could provide a C-level debugserver.  In principle a "C-Bridge"
sub-project could be folded into LLDB pretty easily -- just like we do
for different OS platforms.


But perhaps I am thinking about things the wrong way, or I underestimate
the amount of work needed to "upgrade" the current debug server to use
the Process plugin framework...  I am certainly still open to
either/different approaches.


> > p.s. the one thing that kept me from trying this directly was
> > figuring out where in the Makefile system this got chosen, because
> > by default on linux, the gdb-remote directory isn't built.  If
> > anyone knows where this controlled, please point it out. Thank you!
> 
> I will defer to Stephen Wilson on this one.

We can't commit this yet, but here is the needed patch:


diff --git a/source/Plugins/Makefile b/source/Plugins/Makefile
index fd86444..43f0818 100644
--- a/source/Plugins/Makefile
+++ b/source/Plugins/Makefile
@@ -15,12 +15,11 @@ include $(LLDB_LEVEL)/../../Makefile.config
 DIRS := ABI/MacOSX-i386 ABI/SysV-x86_64 Disassembler/llvm  \
 	ObjectContainer/BSD-Archive ObjectFile/ELF SymbolFile/DWARF \
 	SymbolFile/Symtab Process/Utility DynamicLoader/Static \
-	Platform
+	Platform Process/gdb-remote
 
 ifeq ($(HOST_OS),Darwin)
 DIRS += DynamicLoader/MacOSX-DYLD ObjectContainer/Universal-Mach-O \
-	ObjectFile/Mach-O Process/gdb-remote  \
-	SymbolVendor/MacOSX Process/MacOSX-User
+	ObjectFile/Mach-O SymbolVendor/MacOSX Process/MacOSX-User
 endif
 
 ifeq ($(HOST_OS),Linux)