llvm dev - Oct 2014 - [LLVMdev] LibUnwind into Compiler-RT?

So, I remember we discussed this earlier this year, but I can't find the
thread.

The idea is to move libunwind into compiler-rt for the simple reasons below:

1. Unwinding is not exclusive to C++, nor exception handling.
2. Clang still includes libgcc_s and libgcc_eh when using compiler-rt
(maybe eh isn't needed, but it was there for libgcc).
3. Testing the libunwind with libc++ on ARM is not possible, because
libgcc_s merges RT abi with unwind, duplicating the implementation of
some, but not all, unwind functions.

I'm not sure how the move would take place, but I remember most people
being in favour, so I'm expecting that someone already has a plan. :)

I'm guessing that the libgcc_eh EH functions are implemented in
libc++, while the libgcc_s unwind is in libc++abi. If not, we might
have a hard time linking them together independently.

We'd have to be sure to move the tests as well, which could be the
hardest part, since all libc++ unwind-depending tests would have to
either be moved or rely on implicit dependencies.

An alternative to fix the libc++ tests on ARM would be to require
Compiler-RT to be there as well, but, as I said, Clang links gcc_eh
and gcc_s when you choose --rtlib=compiler-rt, making the exercise
moot.

Or we could just say that libc++ *needs* compiler-RT and call it a day.

Ideas?

cheers,
--renato

I remember there being a ARM EHABI reason why this won't work, but I
don't
remember the specifics. IIRC, had something to do with how c++ rtti is required
to be handled by the catch handlers, and would mean layering problems if we
moved it. Antoine, do you remember the specifics?

On 10/22/14 11:39 AM, Renato Golin wrote:
> So, I remember we discussed this earlier this year, but I can't find
the thread.
> 
> The idea is to move libunwind into compiler-rt for the simple reasons
below:
> 
> 1. Unwinding is not exclusive to C++, nor exception handling.
> 2. Clang still includes libgcc_s and libgcc_eh when using compiler-rt
> (maybe eh isn't needed, but it was there for libgcc).
> 3. Testing the libunwind with libc++ on ARM is not possible, because
> libgcc_s merges RT abi with unwind, duplicating the implementation of
> some, but not all, unwind functions.
I do compiler_rt + libc++abi + libc++ + clang (with a custom ToolChain) testing
of libc++ on bare-metal ARM.... so it is possible. Perhaps you mean to say that
it's not possible to test libunwind on arm-linux when using
compiler_rt?
> 
> I'm not sure how the move would take place, but I remember most people
> being in favour, so I'm expecting that someone already has a plan. :)
> 
> I'm guessing that the libgcc_eh EH functions are implemented in
> libc++, while the libgcc_s unwind is in libc++abi. If not, we might
> have a hard time linking them together independently.
> 
> We'd have to be sure to move the tests as well, which could be the
> hardest part, since all libc++ unwind-depending tests would have to
> either be moved or rely on implicit dependencies.
> 
> An alternative to fix the libc++ tests on ARM would be to require
> Compiler-RT to be there as well, but, as I said, Clang links gcc_eh
> and gcc_s when you choose --rtlib=compiler-rt, making the exercise
> moot.
Clang's code isn't frozen... ;)
> 
> Or we could just say that libc++ *needs* compiler-RT and call it a day.
This makes me uncomfortable (which I gather is what you're going for) in
that
not saying so, and maintaining compatibility to build with libgcc as the rtlib
keeps us honest.


Cheers,

Jon
> 
> Ideas?
> 
> cheers,
> --renato
> 
-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded

On 22 October 2014 19:24, Jonathan Roelofs <jonathan at codesourcery.com>
wrote:
> I do compiler_rt + libc++abi + libc++ + clang (with a custom ToolChain)
testing
> of libc++ on bare-metal ARM.... so it is possible. Perhaps you mean to say
that
> it's not possible to test libunwind on arm-linux when using
compiler_rt?
Yeah, it's hard and clumsy, not impossible.

Basically, I want to avoid requiring people to link against
libunwind+rt+libcxxabi if all they need is libcxx or rt.

>> An alternative to fix the libc++ tests on ARM would be to require
>> Compiler-RT to be there as well, but, as I said, Clang links gcc_eh
>> and gcc_s when you choose --rtlib=compiler-rt, making the exercise
>> moot.
> Clang's code isn't frozen... ;)
I know, I put it there. :)

I did it because that was what libgcc required, and I didn't want to
make compiler-RT depend on libc++, at least not at a Clang level.
Since gcc_s and gcc_eh are both provided by libgcc, it makes sense in
the GNU case. Maybe, a better approach would be to warn users if they
choose compiler-rt (via --rtlib=compiler-rt) and not libunwind or
libgcc_s variants.

The other problem is symbol clashing. If we start including multiple
libraries that implement and export the same symbols, we'll be in
trouble soon enough. This already happens with --rtlib=compiler-rt and
will happen if I include -lgcc_s on libc++abi tests on ARM (for the
RTABI part). Having libunwind on its own repository is also not a
horrible idea, but I don't know the logistics of that.

>> Or we could just say that libc++ *needs* compiler-RT and call it a day.
> This makes me uncomfortable (which I gather is what you're going for)
in that
> not saying so, and maintaining compatibility to build with libgcc as the
rtlib
> keeps us honest.
Me too, but I have to say it's by far the easiest option.

We only have that kind of problem because we split the symbols in a
way that is different than GNU tools, so that we'll always have
clashes when we try to interoperate. The other easy option is to split
in the *exact* same way as libgcc, so that we can mix and match, but
that's not free of problems, either.

Someone with more knowledge in linkers can chime in on how the symbols
are dropped, so that at least we can be sure of which library
overrides which.

cheers,
--renato

On Wed, Oct 22, 2014 at 11:24 AM, Jonathan Roelofs <
jonathan at codesourcery.com> wrote:
> I remember there being a ARM EHABI reason why this won't work, but I
don't
> remember the specifics. IIRC, had something to do with how c++ rtti is
> required
> to be handled by the catch handlers, and would mean layering problems if we
> moved it. Antoine, do you remember the specifics?
>
For a complete implementation, the arm-defined PRs
(__aeabi_unwind_cpp_pr[0-2]) need to call the functions in 8.4.2 in phase
2, which are in libc++abi. In particular, as you mention, __cxa_type_match
needs the rtti info.

That said, currently this part is not implemented in libunwind, among
others because clang never generates code that uses arm-defined PRs for
exceptions and cleanup, only for trivial frame unwinding (it always uses
__gxx_personality_v0 for exceptions/cleanup), so I don't think today
libunwind depends on libc++abi, except for the recent patch for
_Unwind_Backtrace.

Antoine

>
> On 10/22/14 11:39 AM, Renato Golin wrote:
> > So, I remember we discussed this earlier this year, but I can't
find the
> thread.
> >
> > The idea is to move libunwind into compiler-rt for the simple reasons
> below:
> >
> > 1. Unwinding is not exclusive to C++, nor exception handling.
> > 2. Clang still includes libgcc_s and libgcc_eh when using compiler-rt
> > (maybe eh isn't needed, but it was there for libgcc).
> > 3. Testing the libunwind with libc++ on ARM is not possible, because
> > libgcc_s merges RT abi with unwind, duplicating the implementation of
> > some, but not all, unwind functions.
> I do compiler_rt + libc++abi + libc++ + clang (with a custom ToolChain)
> testing
> of libc++ on bare-metal ARM.... so it is possible. Perhaps you mean to say
> that
> it's not possible to test libunwind on arm-linux when using
compiler_rt?
> >
> > I'm not sure how the move would take place, but I remember most
people
> > being in favour, so I'm expecting that someone already has a plan.
:)
> >
> > I'm guessing that the libgcc_eh EH functions are implemented in
> > libc++, while the libgcc_s unwind is in libc++abi. If not, we might
> > have a hard time linking them together independently.
> >
> > We'd have to be sure to move the tests as well, which could be the
> > hardest part, since all libc++ unwind-depending tests would have to
> > either be moved or rely on implicit dependencies.
> >
> > An alternative to fix the libc++ tests on ARM would be to require
> > Compiler-RT to be there as well, but, as I said, Clang links gcc_eh
> > and gcc_s when you choose --rtlib=compiler-rt, making the exercise
> > moot.
> Clang's code isn't frozen... ;)
>
> >
> > Or we could just say that libc++ *needs* compiler-RT and call it a
day.
> This makes me uncomfortable (which I gather is what you're going for)
in
> that
> not saying so, and maintaining compatibility to build with libgcc as the
> rtlib
> keeps us honest.
>
>
> Cheers,
>
> Jon
> >
> > Ideas?
> >
> > cheers,
> > --renato
> >
>
> --
> Jon Roelofs
> jonathan at codesourcery.com
> CodeSourcery / Mentor Embedded
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141022/c55ff097/attachment.html>