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 _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
