Re: [CFT] Update to clang 3.4
On 7 January 2014 03:54, David Chisnall wrote: > On 7 Jan 2014, at 06:49, Rui Paulo wrote: >> Our libdwarf was a from scratch implementation and we never used the LGPL >> libdwarf. I don't know if it's worth investing time upgrading our BSD >> licenced libdwarf or importing the LGPL libdwarf. Given the push to keep >> the tree mostly BSD licenced, I would say the former. I think bringing in a later version of elftoolchain / libdwarf would be straightforward. It seems there would be a fair amount of work left even after doing that though. Specifically, there's a todo item for "Add support for DWARF4 ".debug_types" section": sourceforge.net/apps/trac/elftoolchain/ticket/408. There's still ongoing development in elftoolchain, but I have no idea how likely it is that a usable libdwarf will appear in the near future. Perhaps kaiw@ or jkoshy@ can comment. > LLVM now has fairly complete DRAWF4 parsing support. What interfaces do the > ctf tools need, and are they the only consumers of libdwarf? The ctf tools are indeed the only consumers of libdwarf, and all use is in one file: cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c. It looks like it just parses various DW_TAG types (array, enum, pointer, ...) from .debug_info, and migrating to an LLVM DWARF parser wouldn't be overly difficult. ___ 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"
Re: [CFT] Update to clang 3.4
On 5 January 2014 08:00, Dimitry Andric wrote: > > Second, the shipped version of gdb in our tree is very old, and is > basically unmaintained. Nobody in their right mind should ever use it > for debugging, unless they have no other choice. As soon as the in-tree > version of lldb is in workable state, we should get rid of the base gdb. > > I think the only tricky task left is our custom kgdb hacks, which must > be ported to some newer version of gdb soon, or preferably to lldb. I > have no idea if anybody is working on those. Our in-tree gdb is not particularly useful, but it also supports some debug information that both the ports gdb and upstream gdb do not. I am unaware of anyone working on bringing those changes and kgdb support to the ports gdb; I don't expect I'll be able to. I will work on LLDB kernel debugging support although I don't have a specific timeline yet. ___ 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"
Re: abi::__cxa_demangle provides invalid result on non-mangled symbols
On 9 June 2014 21:48, Ryan Stone wrote: > abi::__cxa_demangle is giving me an invalid result if I pass it a > symbol that is not mangled. This is causing me problems as in my > application, I'm getting symbol names from libelf and have no way of > know a priori whether a symbol is mangled or not. I had the same issue in LLVM, and as hacky as it seems, the solution is to check that the name starts with "_Z" before passing it to __cxa_demangle. For reference the LLVM review for the change is here: http://reviews.llvm.org/D2552 I didn't get around to testing it on Linux; since you have a test application ready it would be interesting to see the result of __cxa_demangle("f") there. ___ 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"
Re: gdb in CURRENT cannot debug userland cores, when is kernel lldb coming?
On 11 June 2014 14:53, Craig Rodrigues wrote: > > Is anyone working on a kernel lldb? When is it expected to be ready? Kernel LLDB support is an ongoing Summer of Code project this year. I'm not sure it's feasible for 10.1 though. ___ 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"
Re: abi::__cxa_demangle provides invalid result on non-mangled symbols
On 10 June 2014 02:38, David Chisnall wrote: > > If you know that the thing that you are demangling is a symbol name, then you > can use the _Z check, which isn't really a hack - it's a marker added to > identify C++ symbols. Note that, if you're writing portable code, you need > to remember that some systems prepend an underscore to all compiler-generated > symbols, so you may also need to check for __Z and trim the leading _. Right, it just feels hackish to have to know this detail of the ABI. I think I'd like an explicit __cxa_demangle_symbol interface, or perhaps __cxa_is_mangled_symbol to query a string. > The __cxa_demangle() function has to handle things that are not just symbols > (types and so on) and so can't do this test itself. Its most common use is > generating a human-friendly error for an uncaught exception, where it is just > parsing a type encoding. My use, and I suspect Ryan's, is demangling symbols obtained from introspection interfaces like backtrace_symbols(3). In any case, our libelftc __cxa_demangle accepts strings that are neither symbols nor NTBS manglings, and can return a bogus demangled name for them. Of course, it's a mistake to rely on __cxa_demangle rejecting these for arbitrary input. ___ 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"
Re: Using more elftoolchain tools?
On 23 November 2014 at 19:09, Baptiste Daroussin wrote: > Hi all, > > From what I can see on the elftoolchain website, they do have working > replacement for: > - size(1) > - addr2line(1) > - strings(1) > - nm(1) > - strip(1) > > Does anyone knows if there are known issues with those? or if they are viable > replacement for the version we have in base? > > I'm planning to spend a bit of time on those (I think emaste@ is already > working > on strip(1) so I'll skip that one). I'll save you the effort, since it was easy to add the rest after getting the first one incorporated into our build. The set above are in code review at https://reviews.freebsd.org/D1224. It adds a WITH_ELFTOOLCHAIN_TOOLS knob to enable building them instead of binutils. I have a -current VM built with that enabled and it passes basic sanity tests. I know that at elftoolchain is missing some required functionality for MIPS at least, but I don't think it'll be hard to add. What I'd like to do is commit the change in D1224 after a little more refinement, then call for broader testing and a ports exp run. We can enable WITH_ELFTOOLCHAIN_TOOLS by default on a per-architecture basis until it works properly everywhere. -Ed ___ 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"
Migration to dynamic libs for llvm and clang
One of goals for the toolchain prior to the FreeBSD 11 branch is to create a libllvm.so and libclang.so for use by all of the LLVM family tools installed in the base system. This message is just a heads-up in case anyone has questions or comments on the idea. We currently build a large number of static libs for the llvm and clang components, which are reused in a number of tools in the LLVM family. The resulting binaries end up quite large, and as a group require a lot of disk space. For example, LLDB includes a copy of Clang, used as its expression parser. As a result, on my desktop /usr/bin/clang and /usr/bin/lldb are both 27MB. Over time we may add additional LLVM family tools (e.g., llvm-objdump), and this will help avoid excessive bloat as we do so. I expect libllvm.so and libclang.so will go in /usr/lib/private. ___ 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"
Re: Migration to dynamic libs for llvm and clang
On 16 December 2014 at 11:15, David Chisnall wrote: > > Upstream doesn't call it libclang (that's the name of the library with a > stable C ABI, which is why I'd like us not to confuse it with something with > a library with an unstable C++ API). They do produce a libLLVM.so from the > LLVM builds and work is underway to have shared library builds for clang. Agreed. Even if there's no potential issue since it will be in /usr/lib/private it would be confusing. David's suggestion of libcfe sounds reasonable. >> That said, I agree with the general idea, but one of the first things >> we should decide is whether this will be optional or not. Having to >> maintain yet another WITH_CLANG_FOO option is burdensome... Fair enough, I'd definitely like to see fewer build-time knobs over time, not more. > I agree. I'd quite like to see performance numbers for the compiler. I > think I saw about a 10% overhead for buildworld last time I tried, but that > was a couple of years ago. Ok. I will put this together in a branch and we can compare results and decide which way to go when we have actual numbers. ___ 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"
Re: Migration to dynamic libs for llvm and clang
On 16 December 2014 at 12:39, Warner Losh wrote: > > We should defer testing until after that import :) Indeed. I have an early WIP patch in a local branch, but any new work before 3.5.x lands will be wasted, so it will be in the new year that I'll have something to start testing. ___ 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"
Re: Migration to dynamic libs for llvm and clang
On 16 December 2014 at 14:47, Warner Losh wrote: > > My comment was > more to Ed’s notion that these numbers will be dropping any time soon. To be clear, I don't expect we'll be dropping knobs soon. We should keep that as a goal to aim for. ___ 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"
Call for testing: elftoolchain tools
We have a rather outdated version of binutils in the base system. As part of a project to update our toolchain I've started working on using some of the tools from the elftoolchain project. There is now a build knob to enable the use of the following tools: * addr2line * elfcopy (strip) * nm * size * strings The knob (in /etc/src.conf) is: WITH_ELFTOOLCHAIN_TOOLS=yes The binutils version is still used for as, ld, objcopy, objdump and readelf; future projects will handle these. The option is being tested in ports exp-runs on amd64 and i386, and has had basic sanity testing on arm64 and mips64. I'm interested in test reports across a variety of hardware architectures and use cases. If everything works as expected you should see no difference -- the tools should be drop-in replacements. -Ed ___ 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"
Re: HEADS UP: Upgraded clang, llvm and lldb to 3.5.0
On 8 January 2015 at 08:45, Craig Rodrigues wrote: > I just tried to build CURRENT with WITH_LLDB=yes > in /etc/make.conf. I got this error: > > ... Thanks for the report Craig, I'm looking at it. ___ 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"
Re: Compiling LLDB
On 30 March 2015 at 19:18, Kenan Ali wrote: > Hi, > > I would like to see if I could get involved with contributing to the kernel > core support for LLDB under FreeBSD. I'm running a FreeBSD-head build (on a > VM) from a week or two ago, and I'm following the instructions from here: > https://wiki.freebsd.org/lldb > > Once I get to the 'ninja lldb' step, it seems that I always end up with the > following error: > > CC: error: unable to execute command: Killed > CC: error: linker command failed due to signal (use -v to see invocation) > Ninja: build stopped: subcommand failed. > > I've tried passing the '-v' flag to ninja, which lists a large invocation > before spewing out the errors above. However, I cannot seem to figure out how > to get the '-v' command passed to LLVM's linker. Neither ninja's help output > or some basic Googling seem to be helping me diagnose this issue, so I was > wondering if anyone here could help? I'd suggest checking /var/log/messages for further information. Is this i386 or amd64, how much memory does your build host have, and are you compiling with debug information or no? If had to guess, you're running out of memory (or running into ulimit) during linking, and the process is being killed as a result. ___ 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"
Re: profile_rt from llvm folks?
On 1 April 2015 at 16:35, Dimitry Andric wrote: > On 01 Apr 2015, at 02:03, NGie Cooper wrote: >> >> Hi all, >>We've recently integrated a version of profile_rt from the llvm >> folks internally to replace gcov for code coverage. I was wondering if >> there was a plan to replace the copy of gcov in FreeBSD with the same >> (either in the base system, ports, or both). > > I personally have no plans to do so, but the build of libprofile_rt.a > was added in r276857, at least. Yes, as of that change one can compile with --coverage, and .gcda and .gcno files will be produced via the functionality in libprofile_rt.a. gcov(1) is able to use them, but when I tried llvm-cov it didn't work correctly; in any case, llvm-cov is now on the roadmap for our toolchain. -Ed ___ 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"
Re: Failed to build rescue with gcc 4.9
On 3 April 2015 at 13:02, Warner Losh wrote: > That shows that something in the list is needed. Likely only crunchhide. > > It doesn’t tell us why we need it, or when we started needing it, or what > other conditions we might need it. This information is critical to document > so we know when we can stop doing it in the future. I’m extremely reluctant > to commit this until we know these details. Yes, it's crunchide. It was broken prior to r277259: |crunchide: Correct 64-bit section header offset | |For 64-bit binaries the Elf_Ehdr e_shoff is at offset 40, not 44. |Instead of using an incorrect hardcoded offset, let the compiler |figure it out for us with offsetof(). | |Differential Revision: https://reviews.freebsd.org/D1543 It's not completely clear to me why we did not encounter this before; a comment before the erroneous write states: /* * update the offset of section header table in elf * header if needed. */ so I presume something about the object file created by gcc 4.9 causes this code to be executed, while builds using the in-tree compiler did not. ___ 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"
Re: clang confuses kgdb on static symbols
On 20 October 2015 at 13:27, John Baldwin wrote: > > If '-gdwarf-4' works then you can just set that in the DEBUG makeoptions as a > test, otherwise try hacking kern.mk to disable this bit: > > # > # Add -gdwarf-2 when compiling -g. The default starting in clang v3.4 > # and gcc 4.8 is to generate DWARF version 4. However, our tools don't > # cope well with DWARF 4, so force it to genereate DWARF2, which they > # understand. Do this unconditionally as it is harmless when not needed, > # but critical for these newer versions. > # > .if ${CFLAGS:M-g} != "" && ${CFLAGS:M-gdwarf*} == "" > CFLAGS+=-gdwarf-2 > .endif Note that Clang defaults to DWARF 2 on FreeBSD, so removing the override in kern.mk isn't sufficient. >From contrib/llvm/tools/clang/lib/Driver/Tools.cpp: else if (!A->getOption().matches(options::OPT_g0) && !A->getOption().matches(options::OPT_ggdb0)) { // Default is dwarf-2 for Darwin, OpenBSD, FreeBSD and Solaris. const llvm::Triple &Triple = getToolChain().getTriple(); if (Triple.isOSDarwin() || Triple.getOS() == llvm::Triple::OpenBSD || Triple.getOS() == llvm::Triple::FreeBSD || Triple.getOS() == llvm::Triple::Solaris) CmdArgs.push_back("-gdwarf-2"); else CmdArgs.push_back("-g"); } It may be time for us to remove this default from Clang. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang confuses kgdb on static symbols
On 20 October 2015 at 15:55, Konstantin Belousov wrote: > > We cannot stop generating dwarf-2 until in tree gdb and kgdb are substituted > by a working replacement. Note that I'm only suggesting removing the baked-in default from Clang, not the setting in kern.mk. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang confuses kgdb on static symbols
On 20 October 2015 at 16:30, Konstantin Belousov wrote: > > Wouldn't this cause another outburst of 'works by default' discussion > from some other place ? Ok, I'll hold off on this until we make progress on the gdb retirement plan. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang confuses kgdb on static symbols
On 20 October 2015 at 17:18, Warner Losh wrote: > >> On Oct 20, 2015, at 3:07 PM, Ed Maste wrote: >> >> On 20 October 2015 at 16:30, Konstantin Belousov wrote: >>> >>> Wouldn't this cause another outburst of 'works by default' discussion >>> from some other place ? >> >> Ok, I'll hold off on this until we make progress on the gdb retirement plan. > > Have the issues with ctfconvert been fixed that caused us to go > to dwarf2 by default? It should be - kaiw imported a new libdwarf when this first came up to pick up new DWARF support. It had a few outstanding issues, but those should now be fixed with my elftoolchain update in r276371 last December. Testing that support is of course one of the prerequisites for changing the default back to DWARF 4. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: LLDB build failure
On 19 July 2016 at 13:40, Jonathan Anderson wrote: > Hello toolchain@, > > When building a recent (r275944) LLDB on stable/11, I've encountered build > failures in tools/lldb-mi (missing symbol llvm_regexec, need to link against > LLVMSupport). This problem doesn't occur on (at least) OS X, so perhaps the > LLVM build bots don't see it. We have a FreeBSD 11 LLDB build bot, which was green as of r272672: http://lab.llvm.org:8011/builders/lldb-amd64-ninja-freebsd11 although I'm not certain exactly what it tests. I build regularly on my stable/10 desktop though and lldb-mi built successfully. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Update on using LLVM's lld linker in the FreeBSD base system
Over the past year or so I have been investigating the state of LLVM's lld linker for use in the FreeBSD base system, to see if it could be used as FreeBSD's system linker. Why do we need a new linker? Compared to the GNU ld 2.17.50 that we have in the FreeBSD base system, lld will bring: * AArch64 (arm64) support * Link Time Optimization (LTO) * New ABI support * Other linker optimization * Much faster link times * Maintained code base I've posted a couple of status updates on the LLVM mailing list: http://lists.llvm.org/pipermail/llvm-dev/2015-November/092572.html http://lists.llvm.org/pipermail/llvm-dev/2016-March/096449.html Since the last update in March several lld developers have implemented much of the missing functionality. The main blockers were symbol version support and expression evaluation in the linker script expression parser. Both are now nearly complete. There are a few features used by the FreeBSD base system that lld developers (intentionally) do not expect to implement, unless they're reasonably widely used in a variety of different software. If they're not implemented we can modify FreeBSD to avoid using them. I'm aware of: -N/--omagic, used by some boot loader components. We can achieve the same effect with a linker script. -dc, used by the rescue build. As long as object files are built specifically for rescue we can probably use -fno-common instead. -r binary to convert binary files into ELF objects, used by some device drivers in kernel and module builds. We can use objcopy(elfcopy) instead. Davide Italiano and Rafael Ávila de Espíndola presented an update on the state of lld at BSDCan 2016: https://www.bsdcan.org/2016/schedule/events/656.en.html At this point I'm confident that lld is going to be a viable linker for the FreeBSD base system, and am beginning to plan its import. I expect the process will look something like this: 1. Update lld along with the Clang/LLVM 3.9 update that dim@ is working on. 2. Add the bmake build infrastructure, installing as /usr/bin/ld.lld on the same architectures that use Clang (amd64, arm, arm64, i386). I don't think there's a need for a WITH_LLD src.conf knob, but will add one if desired. 3. Update lld again (most likely to a snapshot from upstream SVN) once it is able to link an unmodified FreeBSD kernel. 4. Modify the boot loader and kernel builds to avoid using features not implemented by lld. 5. Introduce a WITH_LLD_AS_LD knob to have /usr/bin/ld be a ld.lld hardlink instead of /usr/bin/ld.bfd. 6. Request ports exp-runs and issue a call for testing with 3rd party software. Fix issues found during this process. 7. Switch /usr/bin/ld to ld.lld by default in head for the Clang-using architectures. Add a WITHOUT_LLD_AS_LD knob to switch back to GNU ld. There is (some) support for mips and powerpc in lld, but I'm not sure how well tested it is. RISC-V is not yet supported but there is a desire to have a full LLVM-based RISC-V toolchain. I'm not aware of any plan with respect to sparc64 in lld. In any case, I do not plan to address these architectures in the initial lld work. In the near term they will continue to use GNU ld 2.17.50. I'm interested in your comments, questions and concerns about this plan. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Update on using LLVM's lld linker in the FreeBSD base system
For some reason Warner's email didn't make it to me, but I spotted it in the list archive. Warner writes: > On Mon, Aug 1, 2016 at 3:40 PM, Ed Maste wrote: >> -N/--omagic, used by some boot loader components. We can achieve the >> same effect with a linker script. > > Agreed. Or objcopy even. I'm not sure objcopy (alone) can do what we need, because -N also turns off page alignment for .data. But either way I don't think will be hard to work around. >> 2. Add the bmake build infrastructure, installing as /usr/bin/ld.lld >> on the same architectures that use Clang (amd64, arm, arm64, i386). I >> don't think there's a need for a WITH_LLD src.conf knob, but will add >> one if desired. > > I'm on the fence here. Since it is ld.lld, I'm not sure there's much value > here so long as it falls under one of the clang WITH/WITHOUT symbols. Yeah, I planned to bundle it with some knob that already controls lld's dependencies. >> 4. Modify the boot loader and kernel builds to avoid using features >> not implemented by lld. > > This can be done in parallel starting now. I may take a stab at the boot > loader bits since I think that will be easy. Sounds good. We want to have it done by that point in the list but you're absolutely right that we don't need to wait to start working on it. If it hasn't happened by the time we finish up the earlier tasks I'll look at it then. >> 6. Request ports exp-runs and issue a call for testing with 3rd party >> software. Fix issues found during this process. > > Experience suggests this may be the long poll :) Indeed, and that's a big part of my motivation for trying to make lld more readily available as early as possible, even if we're still waiting on some required features. >> 7. Switch /usr/bin/ld to ld.lld by default in head for the Clang-using >> architectures. Add a WITHOUT_LLD_AS_LD knob to switch back to GNU ld. > > For the WITH/WITHOUT things, this is just a matter of changing the default > MK_foo setting, right? Right. > OK. How does this square up against the gcc 4.2 removal timelines and > plans? Once gcc is gone, we'll have to use an external toolchain anyway > to build mips at least (though clang is close, it isn't there yet despite Sean > Bruno's wonderful work). I'm intentionally trying to keep lld decoupled from GCC 4.2 removal, and don't think it should directly enable (or prevent) any progress there. I don't yet have a good handle on GCC 4.2 removal timelines but will definitely pay attention to progress there and potential interaction with lld work. > What's the timeline for all this stuff, do you think? Significant progress is being made in lld at the moment. I don't want to speak for others who are doing much of the work upstream, but I would not be surprised if within two months we can build a working world and kernel with lld (modulo rescue and boot loader fixes). If testing and ports exp-runs go well I'd guess we could make it the default in head a couple of months after that. > Generally, I like it though. My concerns are mostly with ports and gcc plans. > Though it isn't coupled to gcc, I'd suggest that we want to have a joint plan > for both before we get out the axes. Note this is purely a timing argument, > not whether to get them out, just when :) Yes, fully agree. I want to have lld available as soon as is feasible, but have no intention of trying to remove old GNU ld or GCC 4.2 until a viable path forward exists for all architectures. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Time to enable partial relro
On 26 August 2016 at 10:18, Warner Losh wrote: > > So what's the summary of why we'd want to do that? What benefit does it bring? > Sure, other folks do it, but why? It's a relatively low cost technique to mitigate certain vulnerabilities. rtld needs to write to some sections during load but they don't need to be writeable after starting the program. relro reorders the output sections so that they are grouped together, and rtld remaps them read-only on start. This is often called "partial relro." I don't know of any real downside to enabling it, other than it could possibly break some strangely built third party software. It's been enabled on other platforms for quite some time though and I doubt we'd run into new issues. It doesn't bring a huge benefit by itself though; the PLT is still writeable. Adding "-z now" to the linker invocation produces "full relro" which makes the PLT read-only too. It has a negative impact on process start-up time though. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Update on using LLVM's lld linker in the FreeBSD base system
On 1 August 2016 at 17:40, Ed Maste wrote: > Over the past year or so I have been investigating the state of LLVM's > lld linker for use in the FreeBSD base system, to see if it could be > used as FreeBSD's system linker. > > ... > There are a few features used by the FreeBSD base system that lld > developers (intentionally) do not expect to implement, unless they're > reasonably widely used in a variety of different software. If they're > not implemented we can modify FreeBSD to avoid using them. I'm aware > of: > > -N/--omagic, used by some boot loader components. We can achieve the > same effect with a linker script. Warner addressed this for x86 boot components in r305353. We still have an issue: lld does not support -Ttext, but does have an -image-base option to set the start address. It would be nice to reconcile this and LLVM PR 30269 is open to track this for lld. > -dc, used by the rescue build. As long as object files are built > specifically for rescue we can probably use -fno-common instead. I briefly tried to get the rescue build working with lld, but was not successful and have just left it disabled in my tests. We can investigate this later. > -b binary to convert binary files into ELF objects, used by some > device drivers in kernel and module builds. We can use > objcopy(elfcopy) instead. There is now an lld change in progress to add support for -b binary: https://reviews.llvm.org/D24060 ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Retiring WITHOUT_ELFCOPY_AS_OBJCOPY option
In FreeBSD 11 ELF Tool Chain's elfcopy is by default installed as objcopy. The option to switch back to GNU objcopy is available by setting WITHOUT_ELFCOPY_AS_OBJCOPY in make.conf. As part of the plan to remove the outdated in-tree binutils in FreeBSD 12 I intend to remove the WITHOUT_ELFCOPY_AS_OBJCOPY build knob, after FreeBSD 11.0 is released. The patch is available in a Phabricator code review: https://reviews.freebsd.org/D7337 ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Update on using LLVM's lld linker in the FreeBSD base system
On 1 August 2016 at 17:40, Ed Maste wrote: > Over the past year or so I have been investigating the state of LLVM's > lld linker for use in the FreeBSD base system, to see if it could be > used as FreeBSD's system linker. A quick update: most of the required changes have now made it into LLD, and I'm currently testing with an unmodified upstream LLD. I can now build world and kernel with an out-of-tree LLD (setting XLD=...), when using these src.conf knobs: WITHOUT_BINUTILS WITHOUT_BINUTILS_BOOTSTRAP WITHOUT_BOOT WITHOUT_RESCUE There's some upstream work in progress that may address the the boot issue, or at least part of it. Rescue will still be left for later. LLD 3.9 will be available once dim@'s clang390-import branch is merged to FreeBSD HEAD. Although it's a bit older than the LLD HEAD snapshot I've been using for my testing, it will facilitate further testing and experimentation with LLD (e.g. testing ports builds). ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: RPI3 - clang 3.9.0 issues
On 17 October 2016 at 17:11, Shawn Webb wrote: > > When the kernel is compiled with clang 3.9.0, it seems to freeze after > being loaded by the clang 3.8 boot1.efi/loader.efi. I'm unsure if it's > actually frozen or if simply nothing is being outputted to the console. > Either way, I don't see console messages and the RPI3 _appears_ frozen. This will probably be a bit tricky to track down. Have you tried booting a Clang 3.8-compiled kernel with a Clang 3.9 boot1.efi and loader.efi? Do you get any kernel output, or nothing after the last lines of loader output? ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Update on using LLVM's lld linker in the FreeBSD base system
LLD developers have made much progress since my last update in August. Two options used by the FreeBSD build, -dc and -r, are now implemented. The issues with linker script expression support and symbol version maps have been addressed. At this point an LLD built from subversion can link a working FreeBSD-HEAD kernel and world except for the boot loaders. Here's an update on the plan I posted previously: > 1. Update lld along with the Clang/LLVM 3.9 update that dim@ is working on. > 2. Add the bmake build infrastructure, installing as /usr/bin/ld.lld > on the same architectures that use Clang (amd64, arm, arm64, i386). I > don't think there's a need for a WITH_LLD src.conf knob, but will add > one if desired. Now complete, with Dimitry's import of Clang 3.9.0 in r309124. There is a WITH_/WITHOUT_LLD knob, which defaults to on for amd64 and arm64, and off for all other architectures for now. > 3. Update lld again (most likely to a snapshot from upstream SVN) once > it is able to link an unmodified FreeBSD kernel. This is now possible, but I'm going to wait for 3.9.0 to settle and for the 3.9.1 update to happen first. > 4. Modify the boot loader and kernel builds to avoid using features > not implemented by lld. There are a few outstanding issues in LLD that prevent linking the boot loaders, but I'm hopeful that they will be addressed in the near future. > 5. Introduce a WITH_LLD_AS_LD knob to have /usr/bin/ld be a ld.lld > hardlink instead of /usr/bin/ld.bfd. I've added this already, to allow for testing and experimentation, and to provide some linker on arm64 image builds that can be used to bootstrap a later GNU ld or LLVM lld. It defaults to on for arm64 and off everywhere else. Note that the knob affects the installed linker (/usr/bin/ld), but does not change the linker actually used to build world and kernel, which remains GNU ld. > 6. Request ports exp-runs and issue a call for testing with 3rd party > software. Fix issues found during this process. This can start happening any time now for LLD 3.9.0, either by setting WITH_LLD_AS_LD with poudriere, or by using -fuse-ld=lld in LDFLAGS. For example, % cd /usr/src/bin/ls % LDFLAGS=-fuse-ld=lld make > 7. Switch /usr/bin/ld to ld.lld by default in head for the Clang-using > architectures. Add a WITHOUT_LLD_AS_LD knob to switch back to GNU ld. It's still too early to plan a switch by default. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: WITH_LLVM_LIBUNWIND vs. WITHOUT_LLVM_LIBUNWIND, clang vs. gcc (such as devel/powerpc64-xtoolchain-gcc ): What is intended to be required for C++ exceptions to work?
On 29 November 2016 at 16:46, Mark Millard wrote: > > > Summary: Does using clang 3.9.0 as the system compiler imply one should or > must (eventually?) use WITH_LLVM_LIBUNWIND to have C++ exceptions work? > > Do WITH_LLVM_LIBUNWIND and WITHOUT_LLVM_LIBUNWIND have the same criteria > for what dwarfdump should show for the exception information (if the > information to be shown is to be correct/sufficient for libunwind)? It does not. It should be possible to build a functional system both WITH_ and WITHOUT_LLVM_LIBUNWIND. The compiler is unaware of the _LLVM_LIBUNWIND setting. Both unwind libraries use the same unwind data. Eventually new features may show up in Clang and LLVM's libunwind (and new versions of GNU's unwinder) that won't work with the old unwinder. > Your answer's detail might indicate that I've misdirected the llvm folks > in submittals like https://llvm.org/bugs/show_bug.cgi?id=26844 . > > There is also the question of if/when llvm's libunwind is ready to be used > for powerpc64 or powerpc (or . . .) if there are architecture specifics > involved. That answer might determine when C++ exceptions work (and so > when devel/kyua might have a chance to work) and is sort of separate from > the main question here but is still of interest overall. > > Should powerpc64 and powerpc clang 3.9.0 testing be using > WITH_LLVM_LIBUNWIND ? WITHOUT_LLVM_LIBUNWIND ? Both? For testing I think WITH_LLVM_LIBUNWIND is the interesting case. My eventual goal is to have a functioning Clang, LLD, LLDB, libunwind, and ELF Tool Chain on all of our supported architectures. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: I've submitted llvm bugzilla report 31538 on clang 3.9.1 not supporting the mfpmr and mtpmr instructions used in dev/hwpmc/hwpmc_e500.c
On 4 January 2017 at 17:46, Mark Millard wrote: > I have submitted to llvm (matching up with FreeBSD bugzilla 214904): > > Bug 31538 - FreeBSD head (12) buildkernel based on clang FreeBSD's 3.9.1 > stops for mfpmr and mtpmr instructions not being supported (used in > dev/hwpmc/hwpmc_e500.c ) Thank you. > This report likely should be added to the depends on list in: > > Bug 25780 - [META] Using Clang as the FreeBSD/ppc system compiler Agreed, I've added it there. Please feel free to add other issues you find as blocking 25780; my intent is to have it track all of the outstanding issues preventing a Clang-based "make buildworld buildkernel" from succeeding on any ppc / ppc64. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: /usr/bin/ld.lld on powerpc64: produces a.out for which: ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/powerpc64/reloc.c:374
On 11 January 2017 at 04:15, Mark Millard wrote: > > # ./a.out > ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/powerpc64/reloc.c:374 > Abort trap (core dumped) Would you paste the output of `readelf -r a.out`? ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang on armv6 incorrectly emits call to sincos()
On 11 January 2017 at 09:42, Jia-Shiun Li wrote: > > Think this optimization should be turned off for armv6 from base > clang/llvm, instead of patching individual ports or ports infrastructure. You're right that this needs to be fixed in the compiler or the base system, not individual ports. LLVM has a hasSinCos() and should not be emitting the sincos libcall on platforms that do not have it. Would you care to submit a PR for this? -Ed ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: /usr/bin/ld.lld on powerpc64: produces a.out for which: ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/powerpc64/reloc.c:374
On 11 January 2017 at 21:06, Roman Divacky wrote: > Looks like a progress :) Three questions... > > Is the readelf -a reasonable now? FYI, I just committed an ELF Tool Chain fix (r311941) so readelf should display the relocation types properly now. > If you compile with -g, does the > backtrace make a bit more sense? And finally, can you try to "nexti/stepi" in > gdb from > _start to see where things go wrong? Possibly doing it both for ld linked > a.out > and lld linked a.out and compare where things differ. You can also build rtld with additional debugging by adding -DDEBUG to CFLAGS. In libexec/rtld-elf/Makefile there's an example command line for building it locally, but I've just added CFLAGS+=-DDEBUG to the Makefile in my test tree and built it along with the rest of my full cross build. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: elfdump doesn't support .a files?
On 17 January 2017 at 18:06, Ngie Cooper (yaneurabeya) wrote: > Hi Ed, > I tried running elfdump on a .a archive and it seems that elfdump > doesn’t support this (whereas objdump does). Is this expected? Indeed it does not. We're still using FreeBSD's original elfdump. The ELF Tool Chain project (which provides the objcopy, size, strings etc. that we use) also imported FreeBSD's elfdump and made some enhancements, including the ability to handle .a files. Unfortunately there are a few changes which exist in FreeBSD's elfdump but not ELF Tool Chain's version. We need to port those from FreeBSD to ELF Tool Chain before we can migrate to ELF Tool Chain's elfdump. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang 4.0.0 with_lld_is_ld build
On 7 February 2017 at 17:32, Shawn Webb wrote: > Hey All, > > On a system with clang 4.0.0 already installed with lld as ld, I get the > following error compiling the latest HEAD of projects/clang400-import when > WITH_LLD_IS_LD is set: For now try setting WITHOUT_SYSTEM_COMPILER. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang 4.0.0 with_lld_is_ld build
On 8 February 2017 at 08:10, Shawn Webb wrote: > On Tuesday, 07 February 2017 06:55:44 PM Ed Maste wrote: >> On 7 February 2017 at 17:32, Shawn Webb wrote: >> > Hey All, >> > >> > On a system with clang 4.0.0 already installed with lld as ld, I get the >> > following error compiling the latest HEAD of projects/clang400-import when >> >> > WITH_LLD_IS_LD is set: >> For now try setting WITHOUT_SYSTEM_COMPILER. > > buildworld now works when also setting WITHOUT_SYSTEM_COMPILER. Thanks for the report and testing. I've created https://reviews.freebsd.org/D9487 to set this automatically for now, and later we'll need to add a FreeBSD-specific version to the linker (or just share Clang's FREEBSD_CC_VERSION) and compare the host / in-tree linker versions as well. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: /tmp/ecp.* created during kernel build?
[redirected to freebsd-toolchain] On 24 March 2017 at 08:21, Andre Albsmeier wrote: > > Interesting is also that libc.a grows(!): > > Before the strip: > -r--r- 1 andre wheel 2622684 24 Mar 13:18 libc.a > > After: > -r--r- 1 andre wheel 2713792 24 Mar 13:19 libc.a It seems this is a side effect of the way elfcopy writes the new archive and objects. Using diffoscope to compare libc.a and a stripped libc.a we see a few interesting things: % objcopy --strip-debug /usr/lib/libc.a libc.strip1.a % diffoscope /usr/lib/libc.a libc.strip1.a --- /usr/lib/libc.a +++ libc.strip1.a ├── file list │ @@ -1,1258 +1,1258 @@ │ --- 00083210 1970-01-01 00:00:00.00 / │ +-- 00083210 2017-03-30 19:01:14.00 / * Elfcopy is updating the timestamp on the "/" entry, despite leaving all other archive metadata alone. │ --rw-r--r-- 000 1104 1970-01-01 00:00:00.00 iconvlist.o │ +-rw-r--r-- 000 1184 1970-01-01 00:00:00.00 iconvlist.o * As you discovered output is larger, and this is true for the individual .o files in the .a archive. │ File: lib.a(iconvctl.o) │ ELF Header: │Magic: 7f 45 4c 46 02 01 01 09 00 00 00 00 00 00 00 00 │Class: ELF64 │Data: 2's complement, little endian │Version: 1 (current) │OS/ABI:FreeBSD │ABI Version: 0 │Type: REL (Relocatable file) │Machine: Advanced Micro Devices x86-64 │Version: 0x1 │Entry point address: 0 │Start of program headers: 0 (bytes into file) │ - Start of section headers: 528 (bytes into file) │ + Start of section headers: 536 (bytes into file) │Flags: 0 │Size of this header: 64 (bytes) │Size of program headers: 0 (bytes) │Number of program headers: 0 │Size of section headers: 64 (bytes) │ - Number of section headers: 9 │ - Section header string table index: 1 │ + Number of section headers: 10 │ + Section header string table index: 9 Section headers are at a different offset, elfcopy/strip output has an extra section. ├── readelf --wide --sections {} │ @@ -1,23384 +1,24634 @@ │ │ File: lib.a(iconvlist.o) │ -There are 9 section headers, starting at offset 0x210: │ +There are 10 section headers, starting at offset 0x220: │ │ Section Headers: │[Nr] Name TypeAddr Off Size ES Flg Lk Inf Al │[ 0] NULL 00 00 00 0 0 0 │ - [ 1] .strtab STRTAB 000180 8c 00 0 0 1 │ - [ 2] .text PROGBITS 40 0a 00 AX 0 0 16 │ - [ 3] .rela.textRELA 000150 18 18 8 2 8 │ - [ 4] .comment PROGBITS 4a 53 01 MS 0 0 1 │ - [ 5] .note.GNU-stack PROGBITS 9d 00 00 0 0 1 │ - [ 6] .eh_frame X86_64_UNWIND a0 38 00 A 0 0 8 │ - [ 7] .rela.eh_frameRELA 000168 18 18 8 6 8 │ - [ 8] .symtab SYMTAB d8 78 18 1 3 8 │ + [ 1] .text PROGBITS 40 0a 00 AX 0 0 16 │ + [ 2] .rela.textRELA 000180 18 18 I 7 1 8 │ + [ 3] .comment PROGBITS 4a 53 01 MS 0 0 1 │ + [ 4] .note.GNU-stack PROGBITS 9d 00 00 0 0 1 │ + [ 5] .eh_frame X86_64_UNWIND a0 38 00 A 0 0 8 │ + [ 6] .rela.eh_frameRELA 000198 18 18 I 7 5 8 │ + [ 7] .symtab SYMTAB d8 a8 18 8 5 8 │ + [ 8] .strtab STRTAB 0001b0 1b 00 0 0 1 │ + [ 9] .shstrtab STRTAB 0001cb 4e 00 0 0 1 │ Key to Flags: │W (write), A (alloc), X (execute), M (merge), S (strings) │I (info), L (link order), G (group), x (unknown) │O (extra OS processing required) o (OS specific), p (processor specific) Sections are in a different order, and elfcopy/strip includes a separate section header string table, while Clang's output stores both symbol names and names used in the section header in .strtab. The increased size is interesting and somewhat unfortunate, but not necessarily a bug. > strip (objcopy) does more curious things: > > $ cd /tmp > $ cp /usr/lib/libc.a . > $ strip --strip-debug libc.
April 2017 update on using LLVM's lld linker in the FreeBSD base system
Here's a fresh update on LLVM's LLD linker in the base system, referencing the plan originally posted at the beginning of 2016. This work is primarily taking place on amd64 right now, and unless otherwise noted these results apply to amd64. First, the completed items: > 1. Update lld along with the Clang/LLVM 3.9 update that dim@ is working on. > 2. Add the bmake build infrastructure, installing as /usr/bin/ld.lld > on the same architectures that use Clang (amd64, arm, arm64, i386). > 3. Update lld again (most likely to a snapshot from upstream SVN) once > it is able to link an unmodified FreeBSD kernel. We now have LLD 4.0.0 in the tree and it can build all of FreeBSD/amd64 kernel and world, and most of ports. > 4. Modify the boot loader and kernel builds to avoid using features > not implemented by lld. > 5. Introduce a WITH_LLD_AS_LD knob to have /usr/bin/ld be a ld.lld > hardlink instead of /usr/bin/ld.bfd. This became WITH_LLD_IS_LD for consistency with WITH_CLANG_IS_CC. It also controls the bootstrap linker: adding WITH_LLD_IS_LD=yes to src.conf means that the system will be built with LLD, and LLD will be /usr/bin/ld in the resulting world. This option is currently enabled by default on arm64 (only). Next, where we are today: > 6. Request ports exp-runs and issue a call for testing with 3rd party > software. Fix issues found during this process. This is in progress now, in PR 214864. There are currently 270 failing ports and 963 skipped. The top ten failing ports (by # skipped) are responsible for 808 of the skipped; addressing those should allow us to build nearly 98% of the ports collection with LLD. For reference, the top ten ports by # skipped are: audio/openal-soft devel/libunwind editors/libreoffice lang/fpc print/gl2ps editors/emacs lang/gcc6-aux lang/mono archivers/arj multimedia/libxine Finally, future tasks: > 7. Switch /usr/bin/ld to ld.lld by default in head for the Clang-using > architectures. Add a WITHOUT_LLD_AS_LD knob to switch back to GNU ld. While there is still no timeline set for this, it is already done for arm64 (where we have no in-tree GNU ld available), and it is close to being feasible for amd64. Further investigation is needed on i386 and 32-bit arm before moving forward here. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: April 2017 update on using LLVM's lld linker in the FreeBSD base system
On 5 April 2017 at 16:09, Dimitry Andric wrote: > > Note that as of r316432, all of the above is also available in the > stable/11 branch. However some of the changes to FreeBSD haven't yet been merged to stable/11, and it's probably not possible to build world + kernel with LLD (via WITH_LLD_IS_LD) on stable/11 today. I expect these to be merged over time, but this is still very much an experimental feature right now. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: FYI: amd64 built with WITH_LLD_IS_LD= vs. devel/libunwind : cannot preempt symbol (for various symbols)
On 16 April 2017 at 04:10, Mark Millard wrote: > Context: amd64 FreeBSD -r316952 as a VirtualBox guest > that was built using WITH_LLD_IS_LD= . ports -r438577. > > x11/xorg-minimal indirectly gets to devel/libunwind and > devel/libunwind fails to build from source: > > > --- Lperf-simple --- > libtool: link: cc -O2 -pipe -g -fstack-protector -fno-strict-aliasing > -fexceptions -Wall -Wsign-compare -fstack-protector -o .libs/Lperf-simple > Lperf-simple.o ../src/.libs/libunwind.so -lgcc -llzma -Wl,-rpath > -Wl,/usr/local/lib > /usr/bin/ld: error: ./Gperf-simple.c:195: cannot preempt symbol > '_ULx86_64_init_local' defined in ../src/.libs/libunwind.so The LLD ports exp-run identified the "cannot preempt symbol" issue as being responsible for the largest number of failed or skipped ports. You can find a description of the issue in LLVM PR 30960 (https://bugs.llvm.org//show_bug.cgi?id=30960). This is a tricky issue, and one for which there's not a clear right answer, but is arguably a problem that needs to be addressed in the individual pieces of software (libunwind, openal-soft, etc.) As a temporary workaround you can add CFLAGS+= -fPIC to the port's Makefile, as in https://github.com/emaste/freebsd-ports/commit/4857444b31ca546e29e221dce2a41092765e6062 ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: WITH_LLD_IS_LD vs default WITHOUT_SYSTEM_COMPILER: What are the reasons?
On 14 April 2017 at 20:16, Mark Millard wrote: > So it sounds like I can freely mix WITH_LLD_IS_LD and WITH_SYSTEM_COMPILER > in any system-clang 4.0 based system build context, no actual problem > cases, even if the existing system build used a binutils ld (for example). Yes. WITH_LLD_IS_LD implying WITHOUT_SYSTEM_COMPILER was added because LLD requires tblgen and libllvm, but they were originally built only when needed for Clang. In cases where the SYSTEM_COMPILER default logic determined that the host compiler was identical to the to-be-built bootstrap compiler the build would skip building Clang, tblgen, and libllvm. This was fixed by r316647 and the connection between LLD_IS_LD and SYSTEM_COMPILER can be removed in due course. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: svn commit: r317159 - head/contrib/libstdc++/config/abi/pre
On 19 April 2017 at 15:06, Ed Maste wrote: > Author: emaste > Date: Wed Apr 19 19:06:47 2017 > New Revision: 317159 > URL: https://svnweb.freebsd.org/changeset/base/317159 > > Log: > libstdc++: fix symbol version script for LLD > > LLD is less tolerant of inconsistencies in the symbol version script. > > - Add a ; on the last entry in a version block > - Remove duplicated symbols, retaining those in the earliest block For reference, with this change and two others I was able to link FreeBSD/mips64 world and kernel using the in-tree LLD 4.0.0, although I haven't yet tested the result. Everything was compiled with the in-tree GCC 4.2.1. The other changes I used: 1) applying -mxgot globally, by adding it to CFLAGS in bsd.cpu.mk 2) disabling static_libpam in lib/libpam/Makefile There is a patch in LLVM's Phabricator to add multi-GOT support to LLD[1], although it's meeting some resistance: LLD's main authors don't want the additional complexity in LLD to support ABI oddities that only apply to MIPS. The static libpam failed because it needs to output a relocatable object (ld -r) from multiple input object objects with different/non-zero ri_gp_value, and LLD is not capable of this. [1] https://reviews.llvm.org/D31528 ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
June 2017 update on using LLVM's lld linker in the FreeBSD base system
Another update on using LLD as the FreeBSD base system linker: > We now have LLD 4.0.0 in the tree and it can build all of > FreeBSD/amd64 kernel and world, and most of ports. LLD 4.0.0 is in HEAD and stable/11, and WITH_LLD_IS_LD and WITH_LLD_BOOTSTRAP are enabled by default for arm64 on both branches. There are a few post-4.0.0 bugfixes in LLD that we need to import into HEAD in short order and MFC for the 11.1 release. It is possible to build both the amd64 and arm64 world + kernel with WITH_LLD_IS_LLD and WITH_LLD_BOOTSTRAP. My daily driver desktop and laptop are using LLD as /usr/bin/ld. >> 6. Request ports exp-runs and issue a call for testing with 3rd party >> software. Fix issues found during this process. > > This is in progress now, in PR 214864. There are currently 270 failing > ports and 963 skipped. The top ten failing ports (by # skipped) are > responsible for 808 of the skipped; addressing those should allow us > to build nearly 98% of the ports collection with LLD. bapt@ and I discussed this at BSDCan and we intend to create a way to flag ports that don't build with LLD. Then the ports infrastructure can automatically use ld.bfd, until the issue is addressed in the individual port or in LLD. It will be something like "USES=linker:not_lld" or "LLD_UNSAFE=yes" or so. >> 7. Switch /usr/bin/ld to ld.lld by default in head for the Clang-using >> architectures. Add a WITHOUT_LLD_AS_LD knob to switch back to GNU ld. > > While there is still no timeline set for this, it is already done for > arm64 (where we have no in-tree GNU ld available), and it is close to > being feasible for amd64. Further investigation is needed on i386 and > 32-bit arm before moving forward here. Once the ports infrastructure is in place I plan to enable LLD as /usr/bin/ld by default on amd64. Outstanding issues with i386 and 32-bit arm prevent us from turning it on for those architectures right now. The LLVM tracking bug in http://llvm.org/pr23214 depends on those individual issues; i386 should be relatively straightforward, while arm needs more work. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: June 2017 update on using LLVM's lld linker in the FreeBSD base system
On 12 June 2017 at 17:21, Ed Maste wrote: > Another update on using LLD as the FreeBSD base system linker: Since "amd64" and "arm64" look similar, let me clarify one point: arm64 -- 64-bit ARM -- is built with, and has as /usr/bin/ld, LLD 4.0.0. This is true in HEAD and in stable/11 (and hence the upcoming 11.1) amd64 -- 64-bit x86 -- is built with, and has as /usr/bin/ld, GNU BFD ld 2.17.50. LLD is installed as ld.lld; adding -fuse-ld=lld to CFLAGS can be used to test linking various software with LLD. Also, the amd64 linker will not change in stable/11. > Then the ports infrastructure > can automatically use ld.bfd, until the issue is addressed in the > individual port or in LLD. It will be something like > "USES=linker:not_lld" or "LLD_UNSAFE=yes" or so. Still waiting on this; once it is ready I expect to switch amd64 to LLD. > Outstanding issues with i386 and 32-bit arm prevent us from turning it > on for those architectures right now. The LLVM tracking bug in > http://llvm.org/pr23214 depends on those individual issues; i386 > should be relatively straightforward, while arm needs more work. i386 still needs investigation, but progress has been made on 32-bit arm. andrew@ booted an lld-linked arm kernel/userland to the login prompt, with a few workarounds. Note that this is specifically for armv7. LLD does not currently support earlier ARM architectures. TARGET_ARCH=armv7 support is in discussion/planning, and for now I assume that we'd initially switch only it to LLD. TARGET_ARCH=arm and TARGET_ARCH=armv6 will continue to use ld.bfd. It appears we are on a credible path to enable LLD by default in 12.0 for the tier-1 and almost tier-1 architectures of i386, amd64, armv7, arm64. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: svn commit: r322824 - in head: lib/clang share/mk usr.bin/clang
On 25 August 2017 at 14:07, Ryan Libby wrote: > On Wed, Aug 23, 2017 at 4:30 PM, John Baldwin wrote: >> Author: jhb >> Date: Wed Aug 23 23:30:25 2017 >> New Revision: 322824 >> URL: https://svnweb.freebsd.org/changeset/base/322824 >> >> Log: >> Improve the coverage of debug symbols for MK_DEBUG_FILES. >> ... > This causes llvm to emit hundreds of new warnings [1] for > "DWARF2 only supports one section per compilation unit" > > Are these expected? Are they a concern? Should we silence them? > Is this an upstream llvm bug [2]? I'm not sure they were "expected" but I guess are an unsurprising consequence of building more things with debug. In any case they're not a concern. It is an llvm bug (the warning really ought not be emitted for empty sections), but upstream is probably not too concerned as (most? all) other platforms are not using dwarf2. The right answer for us is likely to just stop defaulting to dwarf2 (and specifying it via CFLAGS for kernel if necessary). ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: svn commit: r325320 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs [breaks lld on zfs: lld uses fallocate]
On 4 November 2017 at 07:41, Andriy Gapon wrote: > On 04/11/2017 12:32, Mark Millard wrote: >> if (int Err = ::posix_fallocate(FD, 0, Size)) { >> if (Err != EOPNOTSUPP) >> return std::error_code(Err, std::generic_category()); >> } > > The commit message that you didn't include into your reply contains some > useful > information that authors / maintainers of this code should probably take into > account: > >> Please note that EINVAL is used to report that the underlying file system >> does not support the operation (POSIX.1-2008). > > Here is a link for that: > http://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_fallocate.html I have no idea how they decided EINVAL was a reasonable errno for this case. Mark, can you give this patch a try: diff --git a/contrib/llvm/lib/Support/Unix/Path.inc b/contrib/llvm/lib/Support/Unix/Path.inc index 45097eb918b7..67edb46f0025 100644 --- a/contrib/llvm/lib/Support/Unix/Path.inc +++ b/contrib/llvm/lib/Support/Unix/Path.inc @@ -427,7 +427,7 @@ std::error_code resize_file(int FD, uint64_t Size) { // If we have posix_fallocate use it. Unlike ftruncate it always allocates // space, so we get an error if the disk is full. if (int Err = ::posix_fallocate(FD, 0, Size)) { -if (Err != EOPNOTSUPP) +if (Err != EINVAL && Err != EOPNOTSUPP) return std::error_code(Err, std::generic_category()); ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Ports and LLVM's lld linker
On 27 November 2017 at 15:39, Ed Maste wrote: > We're making good progress on using LLVM's lld linker as FreeBSD's > /usr/bin/ld, so I'd like to raise awareness of the new linker within > the ports community. With a couple of recent changes in src head (r326831 and r326897) lld is now suitable for use as the base system /usr/bin/ld on amd64 and i386. We're working through ports failures, starting with those responsible for the largest number of skipped ports. The top four, on amd64: port# skipped devel/libunwind 7994 databases/postgresql*-client230 lang/fpc76 lang/mono 22 The remaining failures are responsible for no more than 2 skipped ports each. devel/libunwind fails due to the shared object protected visibility symbol preemption issue; Dimitry Andric and I are searching for an appropriate fix. The databases/postgresql*-client failures have been worked around by r456635, adding LLD_UNSAFE=yes so that the port uses ld.bfd. lang/fpc appears to suffer from stricter validation performed by lld: /usr/bin/ld: error: x86_64/units/x86_64-freebsd/i_linux.o: invalid alignment of section headers lang/mono fails because lld defaults to -z text, disallowing relocations in read-only segments (like .text). A workaround is to add -z notext to the link command line, which turns off lld's error for this case and results in the same behaviour as ld.bfd and ld.gold provide by default. Unfortunately usual workarounds (LLD_UNSAFE=yes or LDFLAGS=Wl,-z,notext) fail for both lang/fpc and lang/mono, and it's not immediately obvious to me how their respective builds handle the options. I'll probably need help from acm@ and mono@ for these. For reference the remaining ports failing with lld on amd64 are: archivers/lua51-zlib audio/alure benchmarks/wrk databases/postgres-xl devel/libds devel/libtecla devel/pdcurses devel/ztcl emulators/gem5 ftp/rexx-curl irc/eggdrop irc/eggdrop-devel irc/evangeline lang/rexx-imc lang/rexx-regutil lang/siod lang/smlnj lang/tclX mail/qmail-dk math/rexx-regmath misc/seabios net-im/uTox net/py-netif net/py-netif print/openprinting print/pdftk security/otpw shells/bash-static sysutils/dupd sysutils/e2fsprogs sysutils/installwatch sysutils/unieject www/cgihtml www/dummyflash www/mod_jk www/mozplugger www/tdom ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Ports and LLVM's lld linker
On 18 December 2017 at 22:10, Ed Maste wrote: > > With a couple of recent changes in src head (r326831 and r326897) lld > is now suitable for use as the base system /usr/bin/ld on amd64 and > i386. We're working through ports failures, starting with those > responsible for the largest number of skipped ports. > > The top four, on amd64: > > port# skipped > devel/libunwind 7994 > databases/postgresql*-client230 These two are now addressed by setting LLD_UNSAFE=yes so that they'll still link with ld.bfd once ld.lld is installed as /usr/bin/ld. The issue with libunwind was already reported upstream (from someone trying to use ld.gold, which fails in the same way), and libunwind's developers will address it in a new version. The postgresql*-client issues need more investigation, but now will not prevent the migration to lld. > lang/fpc76 This one's a little tricky, because it's a (Pascal) tool chain that doesn't support usual environment variables like LD to specify a linker explicitly. > lang/mono 22 I'll mark this one LLD_UNSAFE after a libtool dependency is sorted out (PR224514). After setting LLD_UNSAFE=yes for libunwind some previously-skipped ports attempt to build, and some of those now fail with lld. I'm working through that list and may have a dozen or so more that will become LLD_UNSAFE. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Migrating arm(v7) to LLD_BOOTSTRAP
With the update to Clang/LLVM/lld 6.0.0 I believe lld is nearly ready to be used as the system linker for armv7, and I plan to enable LLD_BOOTSTRAP by default after a couple of WIP patches land and after a little more testing. This may happen a week or two from now. This should have little impact on port builds, because /usr/bin/ld will still be GNU ld.bfd (although there may be some unexpected fallout). I expect to enable LLD_IS_LD by default a little later, and /usr/bin/ld will then be lld. This is the same path we're taking with amd64. lld currently does not support architectures prior to armv7, and fails with some combination of these errors when I try to use it for arm{,v5,v6,eb}: ld: error: lld uses blx instruction, no object with architecture supporting feature detected. ld: error: lld uses extended branch encoding, no object with architecture supporting feature detected. ld: error: lld may use movt/movw, no object with architecture supporting feature detected. I expect this will be addressed in a future version of lld. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Migrating arm(v7) to LLD_BOOTSTRAP
On 17 January 2018 at 00:35, Michal Meloun wrote: > >>> ld: error: lld may use movt/movw, no object with architecture >>> supporting feature detected. > > But this means that we can not use lld for kernel module linking. > (assuming that lld can emits movt/movw with attached relocation). Right now for pre-v7 lld exits with the "may use" before attempting to link, with no indication of whether movt/movw would actually be used. It seems in practice linking armv7 with lld does not use movt/movw. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Heads-up: linker (lld) changes for amd64 coming soon
Some changes related to the amd64 linker are nearly ready to be committed (within a week or three), so I'm sending this notice to request any final comments or concerns before these changes are made. 1. Kostik (kib@) has a patch to start using kernel ifunc, with the first use being Supervisor Mode Access Prevention (SMAP) on amd64. This relies on linker support that is available in the in-tree lld and in contemporary binutils ld.bfd from ports, but not in the in-tree ld.bfd 2.17.50. Right now we use lld as the default bootstrap linker for amd64 in -CURRENT -- that is, the kernel, and userland libraries and binaries are linked with lld. To revert to ld.bfd for amd64 the build-time knob WITHOUT_LLD_BOOTSTRAP=yes can currently be added to src.conf. When the ifunc changes get committed WITHOUT_LLD_BOOTSTRAP=yes will not work for amd64 kernels (and will be added to BROKEN_OPTIONS). 2. WITH_LLD_IS_LD controls whether /usr/bin/ld is ld.bfd or ld.lld, and thus the linker used for linking ports. I plan to switch this to default on. Most ports build just fine when lld is the system linker, but a few encounter trouble: some of the ports rely on options not supported by lld, rely on specific quirks of ld.bfd's implementation, or have a buggy linker invocation that is silently ignored by ld.bfd. The majority of such ports have now been adapted to work with lld or configured to use ld.bfd as the linker, but there are a small number of failing ports that do not provide a way to use other than the default system linker /usr/bin/ld. The outstanding issues can be found in the ports exp-run for lld as /usr/bin/ld, PR214864. Please follow up if you have any concerns or comments about these upcoming changes. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Heads-up: linker (lld) changes for amd64 coming soon
On 27 March 2018 at 02:20, Antoine Brodin wrote: >> 1. Kostik (kib@) has a patch to start using kernel ifunc, with the >> first use being Supervisor Mode Access Prevention (SMAP) on amd64. >> This relies on linker support that is available in the in-tree lld and >> in contemporary binutils ld.bfd from ports, but not in the in-tree >> ld.bfd 2.17.50. > > I have no concerns about 1. OK. My guess is I won't get any other feedback on this one until it makes it into a release. I suspect kib will commit this part later this week or early next week. >> 2. WITH_LLD_IS_LD controls whether /usr/bin/ld is ld.bfd or ld.lld, >> and thus the linker used for linking ports. I plan to switch this to >> default on. >> > > About 2., I am concerned that changes breaking a large number of > ports are committed without portmgr@ approval. > If WITH_LLD_IS_LD is committed as is on amd64, packages for head > won't be published as it doesn't meet our current criteria for > publication. Fair enough - this was the reason I sent the email. I've now gone through and submitted a PR for for each failure that did not already have one. I've also added LLD_UNSAFE to a few ports where where it was straightforward. In this batch of PRs I noticed four main issues: 1. Ports that pass compiler flags, such as -fPIC, to the linker. lld has more strict command-line parsing and rejects these invalid invocations, while ld.bfd happily creates bogus output (e.g. a shared library with a DT_AUXILIARY entry of "PIC"). PR 221808 has a reasonable discussion of this issue. 2. lld has no built-in search paths (/lib, /usr/lib). Normally the linker is invoked from the compiler driver, which provides default search paths. If lld is invoked directly then library search paths must be specified explicitly with -L/lib -L/usr/lib. 3. Shared library protected visibility symbol preemption. 4. lld does not have a built-in default output target. For the common use of the linker (linking individual .o objects into an executable or shared object) lld infers the target from the first object file. However, when the linker is used to convert an arbitrary binary file into an ELF ojbect (via -r -b binary) lld needs the output target to be specified explicitly with -m. The vast majority of skipped ports in the exp-run come from two failures: lang/ghc (PR226872) and lang/fpc (222172). The PR for lang/ghc reports that the current released version of ghc mentions improved lld support; I hope the port update will solve this issue. I submitted a bug report upstream for lang/fpc about one fpc bug that affected lld, and that issue has now been resolved upstream. We'll need to check again once the port is updated. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Heads-up: linker (lld) changes for amd64 coming soon
(Moved from -current to -ports) On 27 March 2018 at 13:15, Ed Maste wrote: > > Fair enough - this was the reason I sent the email. I've now gone > through and submitted a PR for for each failure that did not already > have one. I've also added LLD_UNSAFE to a few ports where where it was > straightforward. Via tobik's commit to lang/myrddin (r465725) I discovered BINARY_ALIAS=ld=ld.bfd, which is a usable workaround for some ports which don't honour $LD or -fuse-ld=bfd in CFLAGS. As you point out in reply to my r465755 BINARY_ALIAS alone is not sufficient, because arm64 does not provide ld.bfd by default and LLD_UNSAFE automatically brings in ports binutils if /usr/bin/ld.bfd does not exist. So we need both LLD_UNSAFE and BINARY_ALIAS. Should we just have LLD_UNSAFE also set BINARY_ALIAS=ld=ld.bfd? ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Heads-up: linker (lld) changes for amd64 coming soon
On 27 March 2018 at 18:21, Ed Maste wrote: > (Moved from -current to -ports) > > On 27 March 2018 at 13:15, Ed Maste wrote: >> >> Fair enough - this was the reason I sent the email. I've now gone >> through and submitted a PR for for each failure that did not already >> have one. I've also added LLD_UNSAFE to a few ports where where it was >> straightforward. > > Via tobik's commit to lang/myrddin (r465725) I discovered > BINARY_ALIAS=ld=ld.bfd, which is a usable workaround for some ports > which don't honour $LD or -fuse-ld=bfd in CFLAGS. As of ports r465900 BINARY_ALIAS is now set automatically if LLD_UNSAFE is set. There are now 14 PRs open for failures when lld is /usr/bin/ld. Thanks to recent commits from krion@ all unmaintained ports that had issues have been addressed, except for print/openprinting (PR221809) and some openal-related failures (PR226980). I'll try to take a look at the openal issues; it's likely that the interim solution will be just to set LLD_UNSAFE in all of the dependent ports. The remaining 12 PRs are all for maintained ports. I believe that now the only port responsible for a significant number of skipped dependent ports is lang/ghc (PR226872). ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Heads-up: linker (lld) changes for amd64 coming soon
On 29 March 2018 at 13:14, Ed Maste wrote: > > There are now 14 PRs open for failures when lld is /usr/bin/ld. Now down to 5: PR 221800 - www/mod_jk Appears to be an issue with libtool passing through linker flags. 0 dependent ports skipped. PR 224673 - misc/seabios Port maintainer has patch ready to be committed. 2 dependent ports skipped PR 226872 - lang/ghc Haskell compiler - the compiler builds fine by using ld.bfd via $LD, but then the built compiler invokes ld. Report in the PR claims the current version (8.4.1) includes some lld support so might "just work" after the port's updated? 558 dependent ports skipped. PR 226975 - x11/eaglemode A common case due to disagreement about preemption of symbols with protected visibility in a shared library. 0 dependent ports skipped. PR 226980 - several ports using openal Ports using openal failed due to the protected visibility symbol preemption issue. LLD_UNSAFE has been added to many of them, with 14 more to go. As a group, 1 dependent port skipped. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Heads-up: linker (lld) changes for amd64 coming soon
On 26 April 2018 at 23:07, Fāng-ruì Sòng wrote: > > I'd like to experiment with LLD --warn-backrefs, which keeps compatibility > with GNU linkers (bfd, gold) in terms of handling of LazyArchive and > LazyObject (see > http://lists.llvm.org/pipermail/llvm-dev/2018-April/122383.html for > details). Ah, thanks for the note. It was not documented in lld's man page; I just added it upstream. > I think a few representative FreeBSD packages may be a great playground to > try --warn-backrefs > > Do you have some pointers on how I can build these packages locally with > --warn-backrefs ? Just adding LDFLAGS=-Wl,--warn-backrefs to /etc/make.conf should be sufficient. I'm not sure of the proper way to replace the linker (with a build from upstream that supports --warn-backrefs) or provide a custom make.conf in Poudriere though, and hope that someone else can provide some guidance on that. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Heads-up: linker (lld) changes for amd64 coming soon
On 26 March 2018 at 22:14, Ed Maste wrote: > Some changes related to the amd64 linker are nearly ready to be > committed (within a week or three), so I'm sending this notice to > request any final comments or concerns before these changes are made. It took somewhat longer than a week or three, but these changes will now happen quite soon. > 1. Kostik (kib@) has a patch to start using kernel ifunc, with the > first use being Supervisor Mode Access Prevention (SMAP) on amd64. > This relies on linker support that is available in the in-tree lld and > in contemporary binutils ld.bfd from ports, but not in the in-tree > ld.bfd 2.17.50. This is ready to be committed at any time. > 2. WITH_LLD_IS_LD controls whether /usr/bin/ld is ld.bfd or ld.lld, > and thus the linker used for linking ports. I plan to switch this to > default on. There was one significant remaining issue in the ports tree with lld as /usr/bin/ld: lang/ghc. This was due (at least in part) to a bug in lld's note handling. The bug is now fixed upstream and in FreeBSD in r333401. The latest version of ghc claims to have improved support for using lld as the linker, and a lang/ghc update is currently in progress (PR227968). Once this is committed I will request one more exp-run with lld. As long as those results are acceptable, I'll then make the switch to install lld as /usr/bin/ld on amd64. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
HEADS-UP: Linker issues building amd64 kernels with config & make
As of r333461 the amd64 kernel makes use of ifuncs, and requires support in the linker. A safety belt added in r333470 enforces this, and will produce an explicit error if the linker does not support ifuncs. lld is the default bootstrap linker for amd64 and has ifunc support. The typical 'make buildworld' (or kernel-toolchain) followed by 'make buildkernel' process will use lld and successfully link a working kernel. The old-style kernel build (using 'config' followed by a 'make' in the kernel directory) uses the host linker (/usr/bin/ld). This still defaults to GNU ld 2.17.50, which does not support ifuncs. This can be worked around in one of two ways: 1. Install lld as the system linker (/usr/bin/ld), by adding WITH_LLD_IS_LD to /etc/src.conf and building and install world. WITH_LLD_IS_LD will become the default on amd64 in the near future - I'm just waiting on updates to the lang/ghc port and another exp-run. 2. Override LD when you build the kernel: $ LD=ld.lld make These tool chain components will undergo additional changes for the next while. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: A head buildworld race visible in the ci.freebsd.org build history
On 18 June 2018 at 19:29, Bryan Drewery wrote: > > The error is coming from libarchive which had a change between those > revisions: > >> >> r328332 | mm | 2018-01-24 06:24:17 -0800 (Wed, 24 Jan 2018) | 14 lines Li-Wen reported that the build is done in a 11.1-rel jail though, so the libarchive (or any userland) change shouldn't be responsible. Can we update a canary builder to somewhere between r328278 and r88? ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Tool Chain Migration: objdump users, please test llvm-objdump
Work is in progress to migrate fully to modern and permissively licensed components for the tool chain. This includes moving away from the three obsolete binutils components that are still in the base system (as, ld, objdump). objdump is a tool to report information about binary objects (such as headers, symbols, etc.), is not required as a build tool, and in any case many uses of objdump are better served by readelf. For FreeBSD 12 I intend to remove GNU objdump 2.17.50. PR 229046[1] is open to track tasks related to its removal, and users who need GNU objdump can install an up-to-date version from the ports tree or the binutils package. That said, llvm includes a somewhat equivalent llvm-objdump, and it is built by default in FreeBSD now. If llvm-objdump's command line option support and output format is "close enough" to GNU objdump for most users we may decide to install it as /usr/bin/objdump. Therefore, I would like to ask users of GNU objdump in FreeBSD to give llvm-objdump a try. Please let me know if it works for your uses, or describe deficiencies that you found. [1] https://bugs.freebsd.org/229046 ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Tool Chain Migration: objdump users, please test llvm-objdump
On 20 June 2018 at 18:25, Shawn Webb wrote: > > Would you like me to quantify the compilation breakages due to the > full llvm toolchain switch? If so, I can do that after July 12th. Thanks Shawn, right now I'm interested specifically in llvm-objdump, with the goal of sorting it out in advance of FreeBSD 12. I think it's a worthwhile endeavour to quantify the breakage from using all of the LLVM tools though, and if you're able to triage the issues and submit LLVM, FreeBSD, or upstream port issues as appropriate that would be much appreciated. (It's just not yet on the critical path for me.) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Tool Chain Migration: objdump users, please test llvm-objdump
On 20 June 2018 at 17:26, Alexander Richardson wrote: > > When I made the change to use llvm-objdump in CheriBSD I had to change the > objdump flags from -xrsSd to -r -s -p -S -d -h -l -t. Ah yes, I recall discussing this now. Per GNU objdump's man page, -x is equivalent to -a -f -h -p -r -t. llvm-objdump doesn't support these: -a archive headers -f file headers so we probably want to address those as well. We'll also need a man page. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Tool Chain Migration: objdump users, please test llvm-objdump
On 21 June 2018 at 09:09, Ed Maste wrote: > > We'll also need a man page. I took a quick look at this, and in doing so found that the output from "llvm-objdump --help" appears to be missing a large number of single-letter options, so one more thing to sort out. As it happens there are LLVM bugs open for a number of the llvm-objdump issues (even including some I submitted but forgot about): https://bugs.llvm.org/buglist.cgi?component=llvm-objdump&list_id=140941&product=tools&query_format=advanced&resolution=--- ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Migrating arm(v7) to LLD_BOOTSTRAP
On 16 January 2018 at 18:45, Ed Maste wrote: > With the update to Clang/LLVM/lld 6.0.0 I believe lld is nearly ready > to be used as the system linker for armv7, and I plan to enable > LLD_BOOTSTRAP by default after a couple of WIP patches land and after > a little more testing. This may happen a week or two from now. This > should have little impact on port builds, because /usr/bin/ld will > still be GNU ld.bfd (although there may be some unexpected fallout). There was one significant issue preventing use of lld for armv7 - it was not handling float type flags in the ELF header. This was just fixed upstream, and I brought the change into FreeBSD in r336972. I believe we're now ready to enable LLD_BOOTSTRAP by default for armv7, and have posted the patch in review D16528[1] for comments/feedback. [1] https://reviews.freebsd.org/D16528 ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Broken arm support in clang now?
On 11 August 2018 at 20:45, Mark Millard via freebsd-toolchain wrote: > > Is the link command itself available? (The .../sys/*/kernel.full.meta > likely has it if it is still around.) I tried a tinderbox build right now and saw the lld warnings from linking zfs.ko. It appears to be fallout from the change to build clang and lld only once for tinderbox, because we're invoking ld from the ${HOST_TARGET} path: /scratch/tmp/emaste/obj/scratch/tmp/emaste/freebsd/freebsd11-amd64/tmp/usr/bin/ld -m armelf_fbsd -Bshareable -znotext -d -warn-common --build-id=sha1 -o zfs.ko.full zfs.kld /scratch/tmp/emaste/obj/scratch/tmp/emaste/freebsd/freebsd11-amd64/tmp/usr/bin/ld: warning: lld uses extended branch encoding, no object with architecture supporting feature detected. /scratch/tmp/emaste/obj/scratch/tmp/emaste/freebsd/freebsd11-amd64/tmp/usr/bin/ld: warning: lld may use movt/movw, no object with architecture supporting feature detected. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Broken arm support in clang now?
On 16 August 2018 at 10:49, Mark Millard wrote: > > Ahh. Okay. 32-bit non-armv7+ cannot be fully llvm based. > Intersting. Indeed; there are a couple of patches in review upstream to address the outstanding issues involved with using lld to link armv5/armv6. > The implication would be that ld was then directly > invoked instead of via cc (clang). Yes, the issue I encountered appears to be a bug in recent logic that shares a single clang and lld for multiple architectures in "make tinderbox." It's directly invoking a newly-built lld. The other issue observed with lld errors from linking arm or armv6 appears to be due to a failure to execute "make buildworld" or "make kernel-toolchain" before "make buildkernel." In this case the build invokes the host's system linker (ld). Previously on amd64 this was the GNU BFD ld, not a cross-linker, and this resulted in an error. Now that amd64's system ld is lld it's inherently a cross linker. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: elfcopy in src.conf
On 11 September 2018 at 14:11, Sid wrote: > Hi, > In src.conf, from 11.2 to 12-current, the elfcopy option was removed, but > objcopy still in the documentation for binutils. I suspect this is about the > toolchain too, and not only in the manpage for src.conf. > > Should objcopy be removed from binutils and from the manpage too? I don't fully follow your question, but will provide some background that I hope answers it - please let me know if it's still not clear. In stable/11 we have a WITH_ELFCOPY_AS_OBJCOPY option which installs ELF Tool Chain's elfcopy as objcopy; if not set the GNU binutils objcopy is installed (and elfcopy is still available under that name). In HEAD we always install ELF Tool Chain's elfcopy as objcopy, and the objcopy man page is actually elfcopy's. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored
On 21 September 2018 at 01:59, Mark Millard via freebsd-toolchain wrote: > In looking into another report about using devel/amd64-gcc to buld > head I tried a build of -r338675 ( with WERROR= ). It got: > ... > > Question: > > Is ignoring "-z ifunc-noplt" a problem for using what > is built? This will have no functional impact, should just result in a missed optimization. (We ought to avoid passing it to non-lld linkers though.) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored
On 21 September 2018 at 15:31, Mark Johnston wrote: > > Perhaps the following? It's not quite right since it'll still use > -zifunc-noplt with an external LLVM toolchain, but I can't seem to > figure out how to define a linker feature for only non-cross toolchains. > In any case, we're going to upstream the option soon. I wouldn't worry too much about out-of-tree since it will be upstream soon as you say, otherwise looks good. > +.if ${MACHINE_CPUARCH} == "amd64" || ${MACHINE_CPUARCH} == "i386" > +.if defined(LINKER_FEATURES) && ${LINKER_FEATURES:Mifunc} == "" > .error amd64/i386 kernel requires linker ifunc support > .endif > +.if defined(LINKER_FEATURES) && ${LINKER_FEATURES:Mifunc-noplt} != "" Maybe roll && defined(LINKER_FEATURES) into the outer .if? ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored
On 23 September 2018 at 07:31, Michael Tuexen wrote: > Using this patch I was able to build/install world and kernel on an i386 > system. > However, after removing it, I can't build world then. When trying to compile a > kernel "the old way" I end up with: > > tuexen@head:~/head/sys/i386/conf % config -g TCP > WARNING: duplicate option `GEOM_PART_GPT' encountered. > Kernel build directory is ../compile/TCP > Don't forget to do ``make cleandepend && make depend'' > tuexen@head:~/head/sys/i386/conf % cd ../compile/TCP/ > tuexen@head:~/head/sys/i386/compile/TCP % make -j 6 > make: "../../../conf/../../../conf/kern.pre.mk" line 126: amd64/i386 kernel > requires linker ifunc support > > This is r338893. > > amd64 works without any problem. So this is i386 specific. Any idea how to > fix it? This safety belt is in place to ensure we don't build a non-functional kernel - now that the i386 kernel requires ifunc support using old GNU ld results in a kernel that doesn't boot. The workaround for the "old way" is to explicitly set LD=ld.lld in the environment - "LD=ld.lld make -j 6" should work. More details in this -arch thread, when amd64 encountered this hiccup: https://lists.freebsd.org/pipermail/freebsd-arch/2018-May/018967.html The same issue now affects i386 as it has started using ifuncs, and will be resolved once we can switch i386's /usr/bin/ld to be lld, which is waiting on ports fixes in PR214864. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: aarch64 head -r338921 vs. man ld vs. ld -v : man ld describes GNU when ld is lld
On 25 September 2018 at 02:06, Mark Millard via freebsd-toolchain wrote: > [This is based on buildworld buildkernel and installing.] > > But man ld reports GNU/BFD material: > > # man ld > LD(1)GNU Development Tools LD(1) ... Odd. I see this on ref12-arm64.freebsd.org as well. It claims to be r334753:336279M, which spans some related work (r335447). Can you find instances of ld.1 in your install log? ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: aarch64 head -r338921 vs. man ld vs. ld -v : man ld describes GNU when ld is lld
On 25 September 2018 at 11:59, Mark Millard wrote: > > install -o root -g wheel -m 444 ld.lld.1.gz /usr/share/man/man1/ > rm -f /usr/share/man/man1/ld.1 /usr/share/man/man1/ld.1.gz; install -l h -o > root -g wheel -m 444 /usr/share/man/man1/ld.lld.1.gz > /usr/share/man/man1/ld.1.gz So this looks like ld.1 should indeed be a link to ld.lld.1. Is it possible you're getting ld.1 from /usr/local? Does /usr/share/man/man1/ld.1.gz exist? ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: aarch64 head -r338921 vs. man ld vs. ld -v : man ld describes GNU when ld is lld
On 25 September 2018 at 14:21, Mark Millard wrote: > > Did you notice the delete-old listing that I provided? It > included: (>>> from delete-old prefix replaced below) No I missed that. > It appears that delete-old should not be listing > /usr/share/man/man1/ld.1.gz as something to potentially delete > in this aarch64 context. Correct. I now have a fix waiting on re@ approval, thanks for the report. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
GNU binutils 2.17.50 retirement planning
For some time we have been incrementally working to retire the use of obsolete GNU Binutils 2.17.50 tools. At present we still install three binutils by default: as ld.bfd objdump The intent is to retire all of these by FreeBSD 13. Depending on tool and architecture we will just remove it, migrate to LLVM tools, or rely on external toolchain components. Retiring GNU as requires further investigation and effort as we have some assembly files (for amd64 at least) which cannot be assembled by Clang's integrated assembler. If Clang gains support for the required functionality we'll switch to using IAS for all assembly files, and if not we could rewrite the few assembly files to work with IAS. ld.bfd is installed, but is not the default linker (/usr/bin/ld) on amd64, arm64 and arm, and soon i386 as well. We can just stop installing it at the appropriate time. For objdump I have proposed installing LLVM's llvm-obdump as objdump, in review D18307. It does not support all of the options that GNU objdump does, but is usable for many common operations. In addition, non-obsolete GNU objdump is available in the binutils port or package. Please try out llvm-objdump and see if it supports the options you need/use, and add a note in PR 229046 if not. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: GNU binutils 2.17.50 retirement planning
On Sun, 25 Nov 2018 at 07:52, David Chisnall wrote: > > We probably need to kill ld.bfd before 12.0. It predates ifunc and so > interprets anything with an ifunc as requiring a copy relocation. I posted https://reviews.freebsd.org/D18340 to stop installing ld.bfd when LLD_IS_LD is enabled. This will have the effect of removing ld.bfd on amd64 (where ifuncs are in use) as well as other architectures which do not yet use ifuncs, but this seems like a reasonable step in the process of removing these obsolete tools. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: GNU binutils 2.17.50 retirement planning
On Sat, 24 Nov 2018 at 17:24, Charlie Li wrote: > > some Makefile logic in stand/i386/btx specify a > hard-coded /usr/bin/as without bootstrapped binutils, necessitating a > symlink. Which logic specifically? I can't seem to find it. > If it is true that the only assembly files that clang IAS cannot > assemble are for amd64 and i386, has there been any research into nasm > and yasm at least? nasm is specified as a build dependency in certain > multimedia/ ports, and yasm in gecko@, for amd64 and i386 assembly code. > Both are licensed under some BSD licence variant. The most significant issue is sys/crypto/skein/amd64/skein_block_asm.s, and it makes extensive use of GNU macro extensions. I have looked at nasm and yasm but believe the macro extension support in those is less developed than in Clang's IAS. There are a number of files in stand/ tagged with CLANG_NO_IAS, in gptzfsboot, cdboot, zfsboot, boot2, and pxeldr. These could likely be removed now (they were added because Clang IAS did not support .codeNN long ago), but they need to be tested first because the generated output is slightly different. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: GNU binutils 2.17.50 retirement planning
On Mon, 26 Nov 2018 at 10:52, Ed Maste wrote: > > The most significant issue is > sys/crypto/skein/amd64/skein_block_asm.s, and it makes extensive use > of GNU macro extensions. I have looked at nasm and yasm but believe > the macro extension support in those is less developed than in Clang's > IAS. > > There are a number of files in stand/ tagged with CLANG_NO_IAS, in > gptzfsboot, cdboot, zfsboot, boot2, and pxeldr. These could likely be > removed now (they were added because Clang IAS did not support .codeNN > long ago), but they need to be tested first because the generated > output is slightly different. In addition to those, on amd64 there are two other sets of .s files currently assembled by GNU as: * i386 boot components (stand/i386/{btx,kgzldr,libi386,mbr,pmbr}) * amd64 linuxulator (sys/amd64/linux{,32}) On i386 there are some others: * kernel (sys/i386/i386) * i386 linuxulator (sys/i386/linux) * dtrace tests (cddl/contrib/opensolaris/cmd/dtrace/test/tst/i386) * vm86 test tool (tools/test/vm86) (Other architectures not yet investigated.) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Linking problem with lld
On Fri, 22 Feb 2019 at 10:09, Willem Jan Withagen wrote: > > My guess is that your linker doesn't support the new symbol versioning > exports and since the symbols are hidden by default they aren't visible > in the shared library. Previously there was a bug (since Luminous and > the switch the cmake) where every public and private symbol was exported > by librados. lld is largely compatible with GNU ld / gold on the command-line and in linker scripts and version scripts. Can you provide the error you see or an example of one of the symbols with incorrect visibility? ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Optimization bug with floating-point?
On Mon, 25 Mar 2019 at 14:32, Steve Kargl wrote: > > This is now > > https://bugs.llvm.org/show_bug.cgi?id=41224 Thanks for submitting a bug report to LLVM, I hope it gets some traction. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: add linker option for LIB32 step on PowerPC64
On Thu, 2 May 2019 at 14:03, Alfredo Dal Ava Junior wrote: > > Hi all, > > I'm working on having PowerPC64 using LLVM by default, but LLD support for 32 > bit seems to be incomplete. As workaround I'm using ld.bfd (2.17) for the > LIB32 step. Ok - eventual goal should be to have 32- and 64-bit linked with lld, but I have no objection to an interim step that uses ld.bfd 2.17.50 for the 32-bit build. Note that there's a goal of removing GCC 4.2.1 and binutils 2.17.50 (requiring external toolchain for architectures that have not migrated to clang/lld). > I found no way to specify the linker for LIB32 step, so I created a variable > called LIB32LD that I pass to "make buildworld". Apparently we'll have to > make this workaround official, so I would like to know your thoughts about > this approach or if you have some other idea to share. I think this would be fine, and it would default to ld.bfd on ppc64? ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Removing obsolete GDB 6.1.1 for FreeBSD 13
We currently have an obsolete version of GDB 6.1 installed as /usr/libexec/gdb, kept only for use by crashinfo(8), which extracts some basic information from a kernel core dump after a crash. If the gdb port is installed crashinfo will use that in preference to /usr/libexec/gdb. If neither exists it will not perform any analysis, reporting "Unable to find a kernel debugger." GDB 6.1.1 was released in June 2004 and is long obsolete. It does not support all of the architectures that FreeBSD does, and imposes limitations on the FreeBSD kernel build - the continued use of DWARF2. I would like to remove GDB 6.1.1 before FreeBSD 13, and propose to switch the GDB knob to default to NO in the near future. If the crashinfo utility and related man pages do not already include references to installing the gdb port/package I will add those before making the change. In the fullness of time we may use LLDB to extract the same information, or provide other tooling to do so, but I do not want to block GDB 6.1.1's removal on this. Please let me know of any objections or comments. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Removing obsolete GDB 6.1.1 for FreeBSD 13
On Wed, 2 Dec 2020 at 12:52, Warner Losh wrote: > > even if lldb isn't a complete drop in replacement (I've not used it at all, > so I can't say one way or another). Quick comment on this point - the FreeBSD Foundation has been sponsoring Moritz Systems to improve LLDB on FreeBSD, and they've done great work getting it into shape. Their work is in LLVM upstream now, and they're iterating on fixing issues found by LLDB's test suite. LLDB 12 should provide a capable userland debugging experience in FreeBSD 13, although I suspect many users will still install the gdb port or package for the familiar command line interface. There's no FreeBSD kernel support in LLDB yet, but it's being investigated. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Removing obsolete GDB 6.1.1 for FreeBSD 13
Adding the FreeBSD-stable list to CC for more visibility. On Wed, 2 Dec 2020 at 12:43, Ed Maste wrote: > > I would like to remove GDB 6.1.1 before FreeBSD 13, and propose to > switch the GDB knob to default to NO in the near future. If the > crashinfo utility and related man pages do not already include > references to installing the gdb port/package I will add those before > making the change. The crashinfo man page now references the gdb port/package, and crashinfo itself emits a message that the port/package should be installed if kgdb is not found. GDB's proposed retirement has now been added to https://wiki.freebsd.org/DeprecationPlan. I expect to make GDB default to NO next week, and then remove it from the tree a week or two later, if there is no compelling objection. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang options for load segments
On Tue, 2 Mar 2021 at 14:37, Paul Floyd wrote: > > I'll work on fixing it in Valgrind, but that is likely to be fair amount > of work. I guess that recent Clang+lld will produce the same PT_LOAD on Linux too, so it seems like this is definitely something Valgrind will need to handle. > No need to hold your breath. Concerning the FreeBSD port I've been > working on Valgrind on FreeBSD for about a year or so and now it's not > too far from working as well on FreeBSD as it does on Linux*. > > Either install the devel/valgrind-devel package (note: not > devel/valgrind) or even better build and install from my github repo > https://github.com/paulfloyd/freebsd_valgrind. I have a commit bit for > upstream Valgrind and am working on integrating FreeBSD support in the > 'official' Valgrind. This probably won't be in the next release, 3.17, > due soon, but I hope that it gets into the next one (3.17.1 or 3.18). > And I'm always on the lookout for any user feedback :-) . Thank you so much for this, I will be very happy to finally see FreeBSD support upstream. IMO we should look at removing devel/valgrind and replacing it with valgrind-devel, given the amount of not-upstream work that exists in both of them. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Differential] [Updated] D1327: Do not strip all when stripping an explicit symbol
emaste updated the summary for this revision. REVISION DETAIL https://reviews.freebsd.org/D1327 To: emaste Cc: freebsd-toolchain ___ 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"
[Differential] [Request, 3 lines] D1327: Do not strip all when stripping an explicit symbol
emaste created this revision. emaste added a subscriber: freebsd-toolchain. REVISION SUMMARY When asked to strip a specific symbol (-N) strip still defaulted to STRIP_ALL. In this case binutils defaults to stripping nothing (other than the requested symbol(s), of course), which makes a lot more sense. PR 196038 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196038 TEST PLAN - reduced test case from PR - build ffmpeg port REVISION DETAIL https://reviews.freebsd.org/D1327 AFFECTED FILES contrib/elftoolchain/elfcopy/main.c To: emaste Cc: freebsd-toolchain ___ 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"
[Differential] [Closed] D1327: Do not strip all when stripping an explicit symbol
emaste closed this revision. emaste updated this revision to Diff 2778. emaste added a comment. Closed by commit rS275862 (authored by @emaste). CHANGED PRIOR TO COMMIT https://reviews.freebsd.org/D1327?vs=2767&id=2778#toc REVISION DETAIL https://reviews.freebsd.org/D1327 AFFECTED FILES head/contrib/elftoolchain/elfcopy/main.c To: emaste, imp Cc: imp, freebsd-toolchain ___ 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"
[Differential] [Request, 11 lines] D1341: Set up default shstrtab entries at initialization
emaste created this revision. emaste added a subscriber: freebsd-toolchain. REVISION SUMMARY If we use -R to remove all sections we still need a .shstrtab (which will itself be the only section entry). Do not wait until the addition of the first non-default entry to create the default ones. Elftoolchain ticket 463 https://sourceforge.net/p/elftoolchain/tickets/463/ TEST PLAN ``` touch empty.s make empty.o strip -o empty-stripped.o -R .text -R .data -R .bss -R .ARM.attributes -R .reginfo -R .gnu.attributes -R .MIPS.abiflags -R .pdr -R .xtensa.info empty.o readelf -S empty.o ``` REVISION DETAIL https://reviews.freebsd.org/D1341 AFFECTED FILES elfcopy/sections.c To: emaste Cc: freebsd-toolchain ___ 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"
[Differential] [Updated] D1341: Set up default shstrtab entries at initialization
emaste updated the test plan for this revision. REVISION DETAIL https://reviews.freebsd.org/D1341 To: emaste Cc: freebsd-toolchain ___ 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"
[Differential] [Closed] D1341: Set up default shstrtab entries at initialization
emaste closed this revision. emaste updated this revision to Diff 2813. emaste added a comment. Closed by commit rS276061 (authored by @emaste). CHANGED PRIOR TO COMMIT https://reviews.freebsd.org/D1341?vs=2791&id=2813#toc REVISION DETAIL https://reviews.freebsd.org/D1341 AFFECTED FILES head/contrib/elftoolchain/elfcopy/sections.c To: emaste, imp Cc: imp, freebsd-toolchain ___ 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"
[Differential] [Request, 191 lines] D1428: readelf: Handle note types from different operating systems
emaste created this revision. emaste added a subscriber: freebsd-toolchain. REVISION SUMMARY Previously elftoolchain readelf(1) only displayed correct names for Linux note types. Upstream elftoolchain ticket #473 https://sourceforge.net/p/elftoolchain/tickets/473/ REVISION DETAIL https://reviews.freebsd.org/D1428 AFFECTED FILES readelf/readelf.c To: emaste Cc: freebsd-toolchain ___ 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"
[Differential] [Commented On] D1428: readelf: Handle note types from different operating systems
emaste added a comment. >>! In D1428#3, @rpaulo wrote: > This looks odd. Why are we relying on magic numbers instead of > constants/enums like before? Some of the constants in the previous version are Linux-specific, and don't exist in our ELF headers. We could make up our own constants (e.g. NT_LINUX_AUXV) but it doesn't seem like that would provide much value. The same constant name may have different values on different OSes. REVISION DETAIL https://reviews.freebsd.org/D1428 To: emaste Cc: rpaulo, freebsd-toolchain ___ 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"
[Differential] [Commented On] D1428: readelf: Handle note types from different operating systems
emaste added a comment. >>! In D1428#6, @rpaulo wrote: > > The Linux note types are Linux specific. Are you saying that FreeBSD reuses > them ? Not quite, just that the note types are vendor-specific and in a namespace specific to the note name (vendor). `NT_PRSTATUS`, `NT_FPREGSET`, and `NT_FPREGSET` happen to have the same value on Linux and FreeBSD. We don't currently have definitions in our ELF headers for Linux-specific note types like NT_LWPSTATUS, and I'd find it somewhat odd to add them without somehow putting them in a namespace in the header. REVISION DETAIL https://reviews.freebsd.org/D1428 To: emaste Cc: rpaulo, freebsd-toolchain ___ 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"
[Differential] [Closed] D1428: readelf: Handle note types from different operating systems
emaste closed this revision. emaste updated this revision to Diff 3002. emaste added a comment. Closed by commit rS276705 (authored by @emaste). CHANGED PRIOR TO COMMIT https://reviews.freebsd.org/D1428?vs=2980&id=3002#toc REVISION DETAIL https://reviews.freebsd.org/D1428 AFFECTED FILES head/contrib/elftoolchain/readelf/readelf.c To: emaste, kostikbel Cc: rpaulo, freebsd-toolchain ___ 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"
[Differential] [Changed Subscribers] D1446: Add the AArch64 llvm backend
emaste added a subscriber: freebsd-toolchain. REVISION DETAIL https://reviews.freebsd.org/D1446 To: andrew, emaste, dim Cc: freebsd-toolchain, emaste ___ 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"
[Differential] [Accepted] D1446: Add the AArch64 llvm backend
emaste accepted this revision. This revision is now accepted and ready to land. BRANCH /head INLINE COMMENTS lib/clang/include/AArch64GenAsmMatcher.inc:1 Please unexpand these before checkin. SVN does the expansion on checkout. I'm not sure if they're collapsed on checkin, or stored verbatim, but don't want to find out :-) REVISION DETAIL https://reviews.freebsd.org/D1446 To: andrew, dim, emaste Cc: freebsd-toolchain, emaste ___ 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"
[Differential] [Commented On] D1446: Add the AArch64 llvm backend
emaste added a comment. >>! In D1446#10, @andrew wrote: > We will also need llvm r92 to build the kernel without using floating > point registers. Can we bring this one directly into HEAD? BRANCH /head REVISION DETAIL https://reviews.freebsd.org/D1446 To: andrew, emaste, dim Cc: freebsd-toolchain, emaste ___ 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"
[Differential] [Commented On] D1446: Add the AArch64 llvm backend
emaste added a comment. I imported this change then merged to my arm64 branch and it looks fine to me. REVISION DETAIL https://reviews.freebsd.org/D1446 To: dim, andrew, emaste Cc: freebsd-toolchain, emaste ___ 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"
[Differential] [Changed Subscribers] D1468: Fix the ARM build of compiler-rt
emaste added a subscriber: emaste. BRANCH /head REVISION DETAIL https://reviews.freebsd.org/D1468 To: andrew, loos, sbruno, rpaulo, ian, dim, imp Cc: emaste, freebsd-toolchain ___ 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"
[Differential] [Updated] D1505: Enable building libclang_rt (asan, ubsan and profile) for selected arches
emaste added a comment. > Apart from the bit of ugliness in lib/Makefile Perhaps the ugliness needs a comment, at least. Also a BSD.debug.mk entry for `WITH_DEBUG_FILES=yes`? REVISION DETAIL https://reviews.freebsd.org/D1505 To: dim, andrew, bapt, imp, emaste Cc: freebsd-toolchain ___ 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"