[LLVMdev] unwind's permanent residence (original) (raw)

C Bergström cbergstrom at pathscale.com
Tue Feb 3 05:15:35 PST 2015

On Tue, Feb 3, 2015 at 7:07 PM, Renato Golin <renato.golin at linaro.org> wrote:

On 30 January 2015 at 20:43, Jonathan Roelofs <jonathan at codesourcery.com> wrote: > Last time we brought this up, there was only partial consensus, and then > someone arbitrarily declared total consensus (without compelling arguments > in any particular direction) that we were going to move it to compilerrt. > Then the discussion fell on the floor because no-one had time to actually do > the move. Please, let's not let that happen again this time.

So, do we have a consensus? AFAICS, the most agree solution (with optionals to be defined): 1. Move Unwinder to its own repository in the LLVM server 2. Make the CMake connections from libc++abi and compiler-rt 2.1 OPTIONAL 1: err if libunwinder is not there, clang errs if rtlib=RT 2.2 OPTIONAL 2: warns if libunwind is not there, clang errs if rtlib=RT 2.3 OPTIONAL 3: nothing, make clang smarter to pick existing unwinder 3. Change clang to assume -lunwind when --rtlib=compiler-rt 3.1 OPTIONAL 4: allow linker error if no -lunwind / -lgccs 3.2 OPTIONAL 5: Add option to change unwinder library by not adding -lunwind/-lgccs, but whatever comes as argument 1, 2, and 3 must be changed. I vote for adding { 2.2, 3.1 } for now, { 2.2, 3.1, 3.2 } for later. My idea for 3.2 is something like --unwinder=libgccs / libunwind, or something like that. I personally don't think the front-end scanning existing libraries is a good thing to do, but I'm not against the idea, if anyone feels strongly about it. If all of us could agree to a common solution, and make sure all interested parties are in, we should do the move before 3.7.

I know I'm in some minority, but whatever ends up happening please be aware that some platforms and targets aren't using the bundled unwind.

Specifically this non-gnu one (aka HP's libunwind permissively licensed) www.nongnu.org/libunwind/download.html

In my experience when it's used in the compiler the name (libgcc, libeh, libunwind) isn't always the same. (So searching for a particular lib name as the unwinder is fragile)

Summary: pretty please allow a cmake option like UNWIND_LIB which can be null or something user defined. (I think this is covered in one of the cases above, but just want to be clear)

Thanks for the minute -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150203/22f4c8c7/attachment.html>

More information about the llvm-dev mailing list