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

[Jason E. Aten]

Sounds reasonable to me, but I'm not really familiar enough with the
architecture to have a super informed opinion.  Following the Keep It Simple
Silly (KISS), and You're Not Going to Need It (YNGNI) principles certainly
appeal to me.

I am however qualified and happy to provide testing and feedback as far as
on the Linux side implementations go, and to do limited ports to linux of
code originally implemented on darwin.  Let me know if I can be of
assistance in either of those two modes.

Jason

On Thu, Mar 17, 2011 at 12:22 PM, Greg Clayton <gclayton at apple.com> 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 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.
>
> So the executable shared library hierarchy would look like:
>
> lldb.so
>  |-Process
>  |  |- ProcessMacOSX
>  |  |- ProcessLinux
>  |-...
>
> Then the binaries would link to lldb.so:
>
> lldb
>  |- lldb.so
>    |- Process
>       |- ProcessMacOSX
>       |- ProcessLinux
>
> debugserver
>  |- lldb.so
>    |- Process
>       |- ProcessMacOSX
>       |- ProcessLinux
>
> Comments?
>
> Greg Clayton
>
> On Mar 16, 2011, at 6:41 PM, Stephen Wilson wrote:
>
> >
> >
> > 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)
> >
> >
> >
>
>


-- 
Jason E. Aten, Ph.D.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20110317/f767823f/attachment.html>