On 3 May 2013, at 20:03, Pedro Giffuni <p...@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: > > http://blogs.everycity.co.uk/alasdair/2011/03/using-the-gnu-ld-linker-on-solaris/ > > There even appears to be a proof-of-concept patch for binutils: > http://sourceware.org/bugzilla/show_bug.cgi?id=13863 > > 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. >> >>> 4.) lldb status >>> >>> Is this described in detail anywhere? > > 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 _______________________________________________ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
