unwind's permanent residence

Although this has been discussed in the past, I think that given a few conversations, it seems that it unfortunately needs to be brought up again.

There seems to be some disagreement over the ideal location of the unwinder (libunwind). Currently, libunwind resides in a subdirectory of libc++abi. There seems to be some desire from multiple parties that it be moved into compiler-rt or a separate repository.

Currently, when using compiler-rt as the runtime library (on Linux) we use libgcc_s and libgcc_eh as the builtins serve as the home for __gcc_personality_v0. This error handling personality requires unwinding support, which these libraries provide. This dependency can be fulfilled with libunwind.

The concern that has been raised with adjusting this dependency has been that libunwind is not guaranteed to be built and installed unless libc++abi is present. The suggestion was that if libunwind were part of compiler-rt or a separate repository, it would be easier to ensure that the required library would be built and installed.

Personally, I am of the opinion that a separate repository for it does make some sense as painful as it sounds. There is a valid point that the unwinder supports the compiler in some sense (for exception handling). It seems that its not particularly as intrinsically tied to the compiler as the builtins are. There is a proper specification that it implements and interface it exposes, so it can be replaced with an alternative implementation. At the same time, the unwinder is not really tied to libc++abi either, though it too has a dependency on it. Again, the use here can be replaced with an alternate implementation (and AIUI, the build system already permits this).

So, I am bringing up this question once more: what can we do about this concern? Is moving it to a separate repository acceptable? Or perhaps moving it to compiler-rt is palatable to more of the involved developers (as much as I may prefer an alternate solution).

There is a valid point that the
unwinder supports the compiler in some sense (for exception handling). It
seems that its not particularly as intrinsically tied to the compiler as the
builtins are.

Unwinding is not just used for EH, but also debugging, profiling,
sanitizers (when in slow-mode) and possibly other code inspection
tools. While still not strictly for *compiler* support, it is for many
other toolchain components.

The counter argument, that libc++ has other low-level code to deal
with exception handling so it would make sense to bundle the unwinder
together, is also compelling. But in my view, less so.

So, I am bringing up this question once more: what can we do about this
concern? Is moving it to a separate repository acceptable? Or perhaps
moving it to compiler-rt is palatable to more of the involved developers (as
much as I may prefer an alternate solution).

For my purposes, bundling it in compiler-rt would be the easiest
solution. It'd also make Clang simpler regarding --rtlib=compiler-rt.
I'm also assuming that libc++ should be able to work with libgcc_s and
other unwinding libraries, and, even if our unwinder is local to it,
it seems very standard in the interface it exports.

However, if libc++ folks don't want to depend on compiler-rt or
libgcc_s for their own unwinding, I don't see a problem in having it
in a separate repository under the LLVM server. One less, one more,
won't make a difference for developers and build systems.

What I don't agree is to leave it as it is, so that even to compile C
code in debug/profile mode, I need to either include libgcc_s or
libc++abi.

cheers,
--renato

I thought the ARM EHABI added a twist to this because it created some upward dependency from the unwinder to libc++abi.

Other than that, I don’t have any strong feeling where it lives.

-Nick

Although this has been discussed in the past, I think that given a few
conversations, it seems that it unfortunately needs to be brought up again.

There seems to be some disagreement over the ideal location of the
unwinder (libunwind). Currently, libunwind resides in a subdirectory of
libc++abi. There seems to be some desire from multiple parties that it
be moved into compiler-rt or a separate repository.

Currently, when using compiler-rt as the runtime library (on Linux) we
use libgcc_s and libgcc_eh as the builtins serve as the home for
__gcc_personality_v0. This error handling personality requires
unwinding support, which these libraries provide. This dependency can
be fulfilled with libunwind.

I think this dependence should be satisfied by the target system's unwinder, whatever that is. If folks want to use this libunwind for their platform, that's fine... but we should probably continue to use libgcc_s and libgcc_eh on linux when that's the platform's unwinder.

The concern that has been raised with adjusting this dependency has been
that libunwind is not guaranteed to be built and installed unless
libc++abi is present. The suggestion was that if libunwind were part of
compiler-rt or a separate repository, it would be easier to ensure that
the required library would be built and installed.

+1 for putting it in a separate repo. Separate repos helps keep layering nonsense to a minimum.

It would be nice if we had some libunwind-specific tests too. Currently we have none, other than the c++ abi tests. Nick, does Apple have any they're willing to upstream?

Personally, I am of the opinion that a separate repository for it does
make some sense as painful as it sounds. There is a valid point that
the unwinder supports the compiler in some sense (for exception
handling). It seems that its not particularly as intrinsically tied to
the compiler as the builtins are. There is a proper specification that
it implements and interface it exposes, so it can be replaced with an
alternative implementation. At the same time, the unwinder is not
really tied to libc++abi either, though it too has a dependency on it.

The fact that this ARM EHABI-induced layering violation is here shouldn't stop us from separating them.

Again, the use here can be replaced with an alternate implementation
(and AIUI, the build system already permits this).

So, I am bringing up this question once more: what can we do about this
concern? Is moving it to a separate repository acceptable? Or perhaps
moving it to compiler-rt is palatable to more of the involved developers
(as much as I may prefer an alternate solution).

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 compiler_rt. 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.

Cheers,

Jon

Although this has been discussed in the past, I think that given a few
conversations, it seems that it unfortunately needs to be brought up
again.

There seems to be some disagreement over the ideal location of the
unwinder (libunwind). Currently, libunwind resides in a subdirectory of
libc++abi. There seems to be some desire from multiple parties that it
be moved into compiler-rt or a separate repository.

Currently, when using compiler-rt as the runtime library (on Linux) we
use libgcc_s and libgcc_eh as the builtins serve as the home for
__gcc_personality_v0. This error handling personality requires
unwinding support, which these libraries provide. This dependency can
be fulfilled with libunwind.

I think this dependence should be satisfied by the target system's
unwinder, whatever that is. If folks want to use this libunwind for their
platform, that's fine... but we should probably continue to use libgcc_s
and libgcc_eh on linux when that's the platform's unwinder.

I think that controlling that via a flag is best if we want to continue
using libgcc_s/libgcc_eh instead of libuwnind.

The concern that has been raised with adjusting this dependency has been
that libunwind is not guaranteed to be built and installed unless
libc++abi is present. The suggestion was that if libunwind were part of
compiler-rt or a separate repository, it would be easier to ensure that
the required library would be built and installed.

+1 for putting it in a separate repo. Separate repos helps keep layering
nonsense to a minimum.

It would be nice if we had some libunwind-specific tests too. Currently we
have none, other than the c++ abi tests. Nick, does Apple have any they're
willing to upstream?

Personally, I am of the opinion that a separate repository for it does
make some sense as painful as it sounds. There is a valid point that
the unwinder supports the compiler in some sense (for exception
handling). It seems that its not particularly as intrinsically tied to
the compiler as the builtins are. There is a proper specification that
it implements and interface it exposes, so it can be replaced with an
alternative implementation. At the same time, the unwinder is not
really tied to libc++abi either, though it too has a dependency on it.

The fact that this ARM EHABI-induced layering violation is here shouldn't
stop us from separating them.

I agree with this.

Again, the use here can be replaced with an alternate implementation

(and AIUI, the build system already permits this).

So, I am bringing up this question once more: what can we do about this
concern? Is moving it to a separate repository acceptable? Or perhaps
moving it to compiler-rt is palatable to more of the involved developers
(as much as I may prefer an alternate solution).

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 compiler_rt.
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.

Im willing to do the leg work if thats what it takes, however, Id like to
get a clear consensus before proceeding.

So far, it seems that there is no argument against moving it into a
separate repository. Everyone agrees that this would be conducive to
ensuring that we don't end up with unintended layering violations. Why
don't we give it a few days to allow others to comment before going with
that solution (hopefully all the particularly interested parties are
already on this thread).

It would be nice if we had some libunwind-specific tests too. Currently we have none, other than the c++ abi tests. Nick, does Apple have any they're willing to upstream?

Here is what Apple has:

   http://opensource.apple.com/source/libunwind/libunwind-35.3/testsuite/

If you think these are useful, I can upstream them. But, they are either generic C++ exception tests (already covered by libc++ tests) or are darwin specific assembly that tests that registers are restored properly. The latter are good things to test in the unwinder but will need some massaging (and a test harness) to work cross platform.

-Nick

I think this dependence should be satisfied by the target system's unwinder,
whatever that is. If folks want to use this libunwind for their platform,
that's fine... but we should probably continue to use libgcc_s and libgcc_eh
on linux when that's the platform's unwinder.

That's precisely the point. People should use unwinders they want, and
libc++abi should be completely agnostic of which one you use.

+1 for putting it in a separate repo. Separate repos helps keep layering
nonsense to a minimum.

It would be nice if we had some libunwind-specific tests too. Currently we
have none, other than the c++ abi tests. Nick, does Apple have any they're
willing to upstream?

+1

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 compiler_rt.
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.

Well, people that didn't mind it in compiler-rt were the last ones to
drop the thread, so it "seemed" like we forced a consensus, but there
really wasn't one. At least, I wasn't convinced, but wasn't bothered
either. Moving to its own repo is also a good solution.

cheers,
--renato

I thought the ARM EHABI added a twist to this because it created some
upward dependency from the unwinder to libc++abi.

Other than that, I don’t have any strong feeling where it lives.

+1 to this. If you don't break the EHABI unwinder while moving things
around, I'm happy.

+Dan, he probably has an opinion on this topic.

I think it would be useful to have this in the test-suite, even if
originally it works mostly on Darwin. We do have buildbots for them,
and at least breaking it will be more public. :slight_smile:

Interested parties can later replicate the tests to their platforms.

cheers,
--renato

The build for the unwinder is already structured such that moving it should be easy enough. I don’t really care if it ends up in its own repo or in compiler-rt, but I think either makes more sense than its current residence.

One argument for putting it in compiler-rt is that compiler-rt aims to be a replacement for libgcc, and libgcc contains an unwinder. That said, I’ve always thought it was strange (and downright inconvenient) that libgcc does this, so I think a separate repo might be best.

It would be nice if we had some libunwind-specific tests too. Currently we
have none, other than the c++ abi tests. Nick, does Apple have any they’re
willing to upstream?

Yes please :slight_smile:

It would be nice if we had some libunwind-specific tests too. Currently we have none, other than the c++ abi tests. Nick, does Apple have any they're willing to upstream?

Here is what Apple has:

    Source Browser

If you think these are useful, I can upstream them.

A few of them look useful almost as-is, for example: unwind_test_main.c, end_of_stack.c, and find_enclosing.c (not an exhaustive list).

But, they are either generic C++ exception tests (already covered by libc++ tests)

More coverage is good :slight_smile:

or are darwin specific assembly that tests that registers are restored properly.
The latter are good things to test in the unwinder but will need some massaging

Those might be a bit more painful to massage into cross-platform goodness. I'm not sure of the best way to replicate this other than to have separate directories full of them, and only try to run them when the testing target is compatible.

(and a test harness) to work cross platform.

Test harness should be a bit easier now... EricWF and Danalbert have been doing lots of great work on the lit harnesses for libcxx/libcxxabi that make them super simple. Adding another harness for unwinder tests should be relatively painless now.

Cheers,

Jon

> I think this dependence should be satisfied by the target system's
unwinder,
> whatever that is. If folks want to use this libunwind for their platform,
> that's fine... but we should probably continue to use libgcc_s and
libgcc_eh
> on linux when that's the platform's unwinder.

That's precisely the point. People should use unwinders they want, and
libc++abi should be completely agnostic of which one you use.

The library is agnostic of the unwinder, the driver is who cares (as it
needs to generate the linker invocation). I think that adding a flag to
control that similar to -rtlib is probably what we may have to do then.

What about the default unwinder for Compiler-RT? Should we assume our own? Gcc’s? Assuming nothing will break compilation, since the libraries won’t be available…

Cheers,
Renato

> The library is agnostic of the unwinder, the driver is who cares (as it
needs to generate the linker invocation). I think that adding a flag to
control that similar to -rtlib is probably what we may have to do then.

What about the default unwinder for Compiler-RT? Should we assume our own?
Gcc's? Assuming nothing will break compilation, since the libraries won't
be available...

I think that assuming libunwind by default is the better choice. Assuming
that GCC is installed is an odd assumption (I don't see anywhere in the
docs that in order to use clang, you *must* have gcc installed in the
standard location). Users can easily change the default behaviour with the
flag if they desire.

Shouldn't it just use the default unwinder for the given platform?

Sure, but what is the default unwinder for a given platform?

Lets go with Linux. I have two different images (okay, I have one, but Im
sufficiently familiar with Gentoo as well):
- Gentoo w/ GCC
- exherbo w/o GCC

Both are Linux. Whats the default unwinder?

be enough to determine that, right?

Yeah, both are linux-gnu. How do you differentiate between libunwind vs
libgcc (-static-libgcc) or libgcc_s between the two? What about when you
are cross-compiling, so, host != target, and therefore cannot use
/etc/*-release?

Talked it over with Saleem on IRC, and I’ve come around to thinking libunwind is a better default for --rtlib=compiler-rt. Reason being that --rtlib=compiler-rt means libgcc probably isn’t even available.

On FreeBSD, we install compiler-rt as libgcc (or, at least, symlink it to libgcc). This means that all compilers can find it and we don't have issues when a gcc-compiled program loads a clang-compiled library (or vice versa).

David