[lldb-dev] FreeBSD fixes

[Filipe Cabecinhas]

Hi,

Sorry for the delay. I started doing some stuff withou replying.

I was creating the Process plugin, but there are some problems, like
repeated enumerations, and some other issues. To minimize syncing  problems,
it would be better for me to start changing DNB.h in-place (if it's
possible), to use lldb's enumerations and other small fixes.

At the same time I would be writing the Process plugin that uses
libdebugnub.

How do you suggest to organize the code? libdebugnub seems to hold as a
library that we could use in lldb for the ProcessHostDebugger, but I'm not
seeing a good place to put it (it's weird to put it in Core/, but it seems
like the best place (or on the Plugin/Process/Utility/ or a
Plugin/HostDebugger/Utility folders).

What do you think?

Regards,

  Filipe


On Thu, Sep 8, 2011 at 16:18, Greg Clayton <gclayton at apple.com> wrote:

>
> On Sep 8, 2011, at 3:58 PM, Filipe Cabecinhas wrote:
>
> > Hi, I tried sending this message earlier, but it seems it got lost along
> the way.
> >
> > I'm re-sending the patch for allowing "target create" on the
> remote-macosx platform and another patch to augment the FreeBSD platform and
> make it like the Mac OS X platform.
> > In order to make the FreeBSD platform we will have to, either implement a
> local platform (like the Linux one) or implement debugserver on FreeBSD. I'm
> leaning on the second solution as it would offer us remote debugging for
> free.
> >
> > I just want to confirm something: Is debugserver portable? I'm supposing
> debugserver is MacOSX specific, but I may be looking at the wrong parts of
> the code.
>
> It is currently very specific. For porting to new systems, we should make
> binary similar to the lldb-platform binary. It links against the innards of
> lldb-core, and it also uses the GDBRemoteCommunicationServer class, which is
> the GDB server side of the GDB remote protocol in LLDB. The
> GDBRemoteCommunicationServer is a very clean interface and gets you all of
> the supported packet management built in. It should be extended to do all of
> the debugging stuff through an interface which is similar to the DNB.h. The
> DNB.h is a very clean interface as well, but we should copy it, and make a
> new version that is host agnostic (there are a few "#include <mach/*>" in
> the DNB.h version). If we abstract all debugging for all systems though a
> clean interface like the one in "DNB.h", then we can also have native
> debugger plug-ins that use this interface and allows us to have a native
> debugger plug-in, _and_ a remote debugger plug-in that use the exact same
> debug code.
>
> So the steps as I see them:
> - Copy DNB.h and remame it to HostDebugger.h and place it into LLDB core
> code and use it as the basis for all local native debugging, both local and
> remote
> - Create a new Process plug-in named ProcessHostDebugger that would use the
> new HostDebugger.h interface
> - Use GDBRemoteCommunicationServer.h to implement a new GDB server binary
> named "lldb-gdb-server" and have it link to lldb-core like lldb-platform
> already does and have it use the "HostDebugger.h" to implement the debugging
> inside GDBRemoteCommunicationServer or a subclass.
>
> We can look at the code in debugserver for reference, but I wouldn't use it
> as the basis for any new GDB server implementations.
>
> Does this make sense?
>
> Greg
>
> >
> > Thanks,
> >
> >   Filipe
> >
> >
> >
> <freebsd-platform.patch><darwin-remote-fix.patch>_______________________________________________
> > lldb-dev mailing list
> > lldb-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20110914/c4c65265/attachment.html>