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

Nick Kledzik kledzik at apple.com
Tue Feb 3 11:44:22 PST 2015

On Feb 3, 2015, at 4:07 AM, 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 This is fine with me. But I thought when I first submitted the source there was push back because we “already have too many repositories”.

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 I assume these are all just about ELF platforms. Darwin does not need any of this logic.

-Nick

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. Please, cast your votes. cheers, --renato

More information about the llvm-dev mailing list