[lldb-dev] lldb on linux -- immediate crash upon attaching to process
wilsons at start.ca
Wed Mar 16 18:41:34 PDT 2011
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
> > 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
@@ -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 Process/gdb-remote
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
More information about the lldb-dev