Date: Sat, 4 May 2013 11:45:18 +0100 From: David Chisnall <theraven@FreeBSD.org> To: Pedro Giffuni <pfg@FreeBSD.org> Cc: freebsd-toolchain@FreeBSD.org Subject: Re: Miscellaneous questions Message-ID: <C28A5826-8526-4A80-80AC-C0DFDC129E1D@FreeBSD.org> In-Reply-To: <518409F9.6030909@FreeBSD.org> References: <CC4D1CB7-1F31-4B46-B0A8-91BBC4F7065A@furosys.com> <518391E2.5000002@FreeBSD.org> <518409F9.6030909@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3 May 2013, at 20:03, Pedro Giffuni <pfg@freebsd.org> wrote: > FWIW, The Solaris people have lived with the problem of supporting > alternative linkers for a while and they came up with LD_ALTEXEC: >=20 > = http://blogs.everycity.co.uk/alasdair/2011/03/using-the-gnu-ld-linker-on-s= olaris/ >=20 > There even appears to be a proof-of-concept patch for binutils: > http://sourceware.org/bugzilla/show_bug.cgi?id=3D13863 >=20 > Again FWIW, one of our linker experts says the patch is ugly but I > wouldn't spend time beautifying GNU ld anyways ;). The patch itself isn't ugly. The concept is, but it's probably sensible = to support something like that. I'm a bit hesitant about that exact = solution, because I don't like the idea of a random environment variable = being able to break (or fix) kernel / world / ports builds. >>=20 >>> 4.) lldb status >>>=20 >>> Is this described in detail anywhere? >=20 > I heard good things about it from a Mac developer but I haven't tried > it. We should look at it. I've used LLDB on OS X, and it is a much nicer experience than gdb. It = does, however, currently lack thread and core dump support on FreeBSD. = We were hoping that Cherry Mathews would work on that, but he is doing = Xen stuff instead. If anyone else is interested, then we have a = proposal that the FreeBSD Foundation has already agreed to fund that it = would be great for someone else to pick up. The proposal is for a bit = more than just finishing the LLDB port, it also includes adding a = less-ugly kernel API for debuggers, replacing ptrace (extending the = process descriptors that were added for capsicum to allow process = control, mmap()ing of a process's address space, and creating thread = descriptors, avoiding some of the race conditions that ptrace has and = providing a cleaner way of copying largish quantities of data to and = from the debugged process and allowing lldb to run in capability mode). > We should also start considering merging the elftoolchain. I'm a bit hesitant about pulling in too much of their stuff, because = we're going to end up with a lot of code duplication if we do. Most of = their utilities have LLVM equivalents, and we're already building all of = the libraries that the LLVM tools depend on. At BSDCan, I'd like to = spend some time in the hacker lounge on the first day with anyone who is = interested going through the source tree, looking at all of the GNU = stuff that we have, and checking what the replacements are going to be. David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C28A5826-8526-4A80-80AC-C0DFDC129E1D>