[lldb-dev] FreeBSD fixes

[Greg Clayton]

On Sep 14, 2011, at 11:13 AM, Filipe Cabecinhas wrote:

> 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.

Please don't change DNB.h in place, we currently use this for our remote debugging and we can't afford any side affects from any changes. It might be good to duplicate and rename the file, possibly to "NativeDebug.h" and move it into "Host" since this is a host debugging issue and the implemenatations are going to host specific and often require native headers in order to compile. We will want to change the DNB prefix on all functions to something else like LLDBHostDebug.

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

Yeah, the DNB.h  (or now "Host/NativeDebug.h"??) interface could also be placed into a dylib, or just linked in as a static library or using the .o files.

> 
> 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).

This would be a Host specific thing, so I would vote for "lldb/Host/NativeDebug.h" or "lldb/Host/Debug.h". 

> 
> 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
> 
>