gdb (Re: lldb ...)

[Fred Wright]

On Thu, 1 Sep 2016, [ISO-8859-1] René J.V. Bertin wrote:

> On Wednesday August 31 2016 17:29:54 Lawrence Velázquez wrote:
>
> >The gdb port instructs the user to modify a system LaunchDaemon to
> >effectively circumvent taskgated. I frankly think that's an awful idea,
> >and future ports should not follow its example.
>
> They certainly shouldn't if there are other ways to get the software to work.
>
> As to gdb, is it even possible to make it work normally? Last times I
> tried gdb it was at least crippled for code written in C++.
>
> I'm tempted to say that as long as gdb cannot be a true alternative to
> lldb there's little point in maintaining the port if in addition it
> requires users to do all kinds of unhealthy things. It's not like it's
> particularly difficult to build gdb (for the port's target audience at
> least).

It's still quite useful to have gdb for cross-debugging in cases where the
relevant stub/server is for gdb rather than lldb.  Although lldb in
principle works with the gdb stub, it expects to get a machine description
from the stub that's not present in the gdb case.  There's an alternative
way to supply the MD to lldb as a Python module (if it exists for the
relevant architecture), but my experience with that approach has been less
than satisfactory, and I didn't take the time to track down why.

I don't think the cross-debugging case should require any interactions
with taskgated, so any mention of taskgated tweaking should probably say
that it's only needed for *local* debugging.

At least the taskgated tweak doesn't open anywhere near as big a security
hole as what you need to do to run your own kexts on >=10.10. :-)

Fred Wright