Date: Mon, 5 Jul 2021 18:56:10 +0100 From: Alexander Richardson <arichardson@freebsd.org> To: Ed Maste <emaste@freebsd.org> Cc: "freebsd-toolchain@FreeBSD.org" <freebsd-toolchain@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, Dimitry Andric <dim@freebsd.org> Subject: Re: Migrating to LLVM binutils tools (ar, nm, addr2line, etc.) Message-ID: <CA%2BZ_v8pd=f8%2BJ6-C0TXCOioRqVv6fNR8wys2zQM=sKOwgiHFPQ@mail.gmail.com> In-Reply-To: <CAPyFy2AP8b4QAU7S9_Yenj8VCWwrBUitRGAAuPiExiX3wBNu%2Bw@mail.gmail.com> References: <CAPyFy2AP8b4QAU7S9_Yenj8VCWwrBUitRGAAuPiExiX3wBNu%2Bw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 5 Jul 2021 at 16:09, Ed Maste <emaste@freebsd.org> wrote: > > FreeBSD migrated from GNU binutils to versions from ELF Tool Chain, > starting in 2014. At that time there were no usable LLVM versions of > those tools, but they have been developing rapidly since then. Now I > think it may be prudent to migrate to the LLVM tools where they exist, > for both functionality and maintainability reasons. > > I'd like to allow use of link-time optimization (LTO) in the FreeBSD > base system. LTO runs optimization passes over the entire executable > (or library) at link time and thus allows for more effective > optimization than when performed on individual compilation units. > > When using LTO object files (.o) including those contained in static > library archives (.a) contain LLVM IR bitcode rather than target > object code. This means that utilities that operate on object files > need to support LLVM IR; we currently use a number of bespoke tools > and ones obtained from ELF Tool Chain that do not have this support. > > Alex Richardson also pointed out that asan (address sanitizer) > produces a useful backtrace only if addr2line is llvm-symbolizer. > > Like ELF Tool Chain the LLVM tools aim for command line and output > format compatibility with GNU binutils, although there are a few minor > differences. Where these cause a material issue (breaking a port or > eliminating required functionality) we can submit LLVM bugs and work > on patches. > > In the past we provided build knobs to control individual utilities > (e.g. WITH_LLD_IS_LD); I'd like to avoid perpetuating that here. It > seems individual knobs (WITH_LLVM_AR_IS_AR, WITH_LLVM_NM_IS_NM, > WITH_LLVM_SYMBOLIZER_IS_ADDR2LINE etc.) will introduce extra > complexity without adding much value. > > Alex is working on a patch now and will follow up shortly, but I > wanted to email the list as a heads-up, and see if there are any > comments or concerns. Thanks for writing this up, I've posted the initial patch as https://reviews.freebsd.org/D31060. > > Potential next steps are: > - Introduce new build knob > - Iterate on exp-runs and call for testing > - Switch to LLVM tools by default > - Major release (14.0) > - Retire knob, leaving only the LLVM implementation.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BZ_v8pd=f8%2BJ6-C0TXCOioRqVv6fNR8wys2zQM=sKOwgiHFPQ>