LLGS for Free/NetBSD (was: Re: [PATCH] D25756: FreeBSD ARM support for software single step.)

Subprojects LLDB
1

Moving the discussion to lldb-dev.

Thanks Pavel! I'll start working on it. Do you know when lldb-server Linux changes were committed? I want to use those patches as a template, but it's hard to locate them digging through thousands of commit log entries...

The original remote debug support for linux came as a long series of
patches in February 2015, between r227909 and r227933. However, it
has gone through quite a bit of rewrite since then, so I'd be wary of
using it as an inspiration. I think you'd be better off using the
current state of the linux support instead. You can also find r240543
interesting as well, which removes the old local debug path. That can
be useful to figure out how to setup lldb to launch lldb-server for
debugging (generally, it boils down to returning "true" from
PlatformXXX::CanDebugProcess()).

krytarowski added a comment.

I just scrolled the discussion so it's not really started. Thanks.

My plan is to work on ptrace(2) for about a month.

Then I will take the FreeBSD code as it is and port to NetBSD trying to make it functional. This is difficult part as there is everywhere OS specific interfaces and behavior. I hope to get it to some usable point after a month.

Then ,I will start working on remote debugging, as my previous patch for process tracing (it was buggy) was rejected without this property. I planned to merge my previous work with master as I was forced to keep catching up after the project changes and it was time expensive, and move my focus on proper platform support.

It's not my place to tell you how to work, but I'd recommend a
different approach to this. If you base your work on the current
FreeBSD in-process plugin, then when you get around to actually
implementing remote support, you will find that you will have to
rewrite most of what you have already done to work with lldb-server,
as it uses completely different class hierarchies and everything. I'd
recommend starting with lldb-server right away. It's going to be a bit
more work as (I assume) freebsd implementation is closer to what you
need than linux, but I think it will save you time in the long run. I
can help you with factoring out any linux-specific code that you
encounter.

cheers,
pl

2

I definitely second the approach Pavel suggests here, and am happy to
work with others on refactoring the Linux lldb-server so that we can
get it to support both FreeBSD and NetBSD at the same time.

A direct port of the current FreeBSD support probably would result in
a basic level of support running sooner, but that work would be
largely thrown away in a future migration to lldb-server.

3

I will take your recommended path as it will lead to the same goal.

I will try to shorten my initial work on ptrace(2) leaving additional
features+tests for later and jump to lldb-server as soon as possible.

For start, before switching to process plugin stage is to extend NetBSD
ptrace(2) with the following features:

- PT_LWPINFO extend struct ptrace_lwpinfo with additional fields used
in LLDB in the current FreeBSD process code (pl_flags, pl_child_pid,
pl_siginfo),

- PT_GETNUMLWPS - number of kernel threads associated with the traced
process,

- PT_GETLWPLIST - get the current thread list,

- PT_SUSPEND - suspend the specified thread,

- PT_RESUME - resume the specified thread.

I need to add basic tests for new ptrace(2) calls in our automated test
infrastructure in order to get this code accepted.

I will reschedule debug registers and additional ptrace(2) calls for the
end, if time will permit.

I will also add support in LLDB for handling NetBSD Real-Time signals
(SIGRTMIN..SIGRTMAX) as it was already implemented during the latest
GSoC for NetBSD (thanks Google!).

I might need some guidance from LLDB developers (I prefer via IRC and
the dedicated LLDB channel) and maybe proof reading of patches and
debugging issues. I consider that the difficult part is not adapting
FreBSD or Linux specific implementation for NetBSD, but taking
everything to work.

My ultimate deadline for the overall LLDB work is February 28th, 2017 -
as I'm switching to Swift port for NetBSD *.

This work is sponsored by The NetBSD Foundation. If you like it, please
consider supporting it by making a donation.

* NetBSD Blog

4

>
> It's not my place to tell you how to work, but I'd recommend a
> different approach to this. If you base your work on the current
> FreeBSD in-process plugin, then when you get around to actually
> implementing remote support, you will find that you will have to
> rewrite most of what you have already done to work with lldb-server,
> as it uses completely different class hierarchies and everything. I'd
> recommend starting with lldb-server right away. It's going to be a bit
> more work as (I assume) freebsd implementation is closer to what you
> need than linux, but I think it will save you time in the long run. I
> can help you with factoring out any linux-specific code that you
> encounter.

I definitely second the approach Pavel suggests here, and am happy to
work with others on refactoring the Linux lldb-server so that we can
get it to support both FreeBSD and NetBSD at the same time.

A direct port of the current FreeBSD support probably would result in
a basic level of support running sooner, but that work would be
largely thrown away in a future migration to lldb-server.

Just to throw out another option: DS2 (DebugServer2) at
GitHub - facebookarchive/ds2: Debug server for lldb. may be another option to getting remote
debugging working. It already has basic BSD support, so adding NetBSD
support shouldn't be too difficult.

5

It's an interesting program, but for now I would leave it for later as
it's out of LLDB.