This is an archive of the discontinued LLVM Phabricator instance.

Make _LIBUNWIND_SUPPORT_FRAME_APIS not conditional on target architecure.
ClosedPublic

Authored by saugustine on Aug 15 2023, 11:50 AM.

Details

Reviewers
MaskRay
Group Reviewers
Restricted Project
Commits
rG5eb44df1b64d: Make _LIBUNWIND_SUPPORT_FRAME_APIS a build-time option
Summary

The functions this macro protects are stubs for libgcc-compatibility.
Today, libunwind as a drop-in replacement for libgcc_eh links on x86,
x86_64, and powerpc, but not aarch64, which doesn't really make
sense. As there is nothing architecture specific about these, they
should be provided everywhere or nowhere.

The target-specific protection goes all the way back to the original
code contribution in 312fcd0e1cf14482b2ae8eee8234541dcc3bc2c4 from
2013, so the original reason is lost to history, and probably not
relevant today.

It may make sense to make this a top-level configure option, or
possibly to get it on defined(linux) but either default has some
compatibility issues--they would either be available in unexpected
places, or not available in expected places. Just like with this
patch. Please advise.

Diff Detail

Event Timeline

saugustine created this revision.Aug 15 2023, 11:50 AM
saugustine requested review of this revision.Aug 15 2023, 11:50 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptAug 15 2023, 11:50 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript

I think that this needs to be more surgical. These shouldn't be enabled on Darwin I believe if this is for libgcc compatibility.

What exactly do you recommend here? The situation is pretty messy.

Today the macro only guards them for target architecture, so they are enabled for Darwin on x86 today, but not Darwin on aarch64. That is true for every single OS that runs on (one of x86, x86_64, and powerpc) and anything else.

So the same problems that exist for Darwin also exist for Fuschia and FreeBSD and many others.

Perhaps a top-level CMake option would be best.

philnik added subscribers: Restricted Project, philnik.Aug 16 2023, 10:52 AM

What exactly do you recommend here? The situation is pretty messy.

Today the macro only guards them for target architecture, so they are enabled for Darwin on x86 today, but not Darwin on aarch64. That is true for every single OS that runs on (one of x86, x86_64, and powerpc) and anything else.

So the same problems that exist for Darwin also exist for Fuschia and FreeBSD and many others.

Perhaps a top-level CMake option would be best.

I think this is actually required on Darwin, since Apple used to ship libstdc++ on x86 at some point in the past. A CMake option seems to me like the sensible solution. Adding libc++ vendors, since they might have some insight here.

Yeah, having control at build time seems entirely reasonable to me.

Switch to _LIBUNWIND_SUPPORT_FRAME_APIS a build-time option

What exactly do you recommend here? The situation is pretty messy.

Today the macro only guards them for target architecture, so they are enabled for Darwin on x86 today, but not Darwin on aarch64. That is true for every single OS that runs on (one of x86, x86_64, and powerpc) and anything else.

So the same problems that exist for Darwin also exist for Fuschia and FreeBSD and many others.

Perhaps a top-level CMake option would be best.

I think this is actually required on Darwin, since Apple used to ship libstdc++ on x86 at some point in the past. A CMake option seems to me like the sensible solution. Adding libc++ vendors, since they might have some insight here.

These symbols are unneeded by ELF systems. See D158241 for an analysis of GCC and Clang.

It's fairly likely that Mac OS doesn't need them as well.
It's possible that Power Mac (llvm-project has dropped support) needed the symbols at one point as a workaround, or these empty symbols were just added for no good reason. (https://en.wikipedia.org/wiki/Mac_transition_to_Intel_processors https://en.wikipedia.org/wiki/Mac_transition_to_Apple_silicon)
It's likely 10+ years no new __register_frame_info references has been generated.

I think defaulting LIBUNWIND_ENABLE_FRAME_APIS to OFF is fine.

Any last comments on this?

MaskRay accepted this revision.Aug 21 2023, 1:38 PM

LGTM if LIBUNWIND_ENABLE_FRAME_APIS defaults to OFF

libunwind/CMakeLists.txt
54

LGTM if this is changed to OFF

55

delete this blank line

This revision is now accepted and ready to land.Aug 21 2023, 1:38 PM

We shall need D158241 first for the llvm-libgcc subproject to suppress ld.lld --no-undefined-version errors.

GCC uses __register_frame_info and friends on platforms where the eh_frame_hdr/eh_frame sections are not supported such as AIX. But we can turn the macro on if GCC compat is needed on those OSs.

Adjust based on feedback

saugustine marked 2 inline comments as done.Aug 23 2023, 2:05 PM
MaskRay accepted this revision.Aug 23 2023, 2:10 PM
This revision was landed with ongoing or failed builds.Aug 23 2023, 2:34 PM
This revision was automatically updated to reflect the committed changes.

It's really confusing that the commit that landed says:

Default this to on, so as not to remove the apis from environments that already have them.

FWIW, this is used by rust on i686 mingw: https://github.com/rust-lang/rust/blob/36b8e4aa7588c70947419a5b435b6faa66669cbd/library/rtstartup/rsbegin.rs#L82

It's really confusing that the commit that landed says:

Default this to on, so as not to remove the apis from environments that already have them.

FWIW, this is used by rust on i686 mingw: https://github.com/rust-lang/rust/blob/36b8e4aa7588c70947419a5b435b6faa66669cbd/library/rtstartup/rsbegin.rs#L82

Note that these __register_frame_* symbols are empty in llvm-project/libunwind and do not really work.
rust i686 mingw should use weak references like GCC libgcc/crtstuff.c does. mingw supports .refptr. to make an unresolved symbol value 0.
(I probably should add more detail to https://maskray.me/blog/2021-04-25-weak-symbol when I understand mingw better...)

Rust doesn't use LLVM's libunwind for mingw-w64, it relies on libgcc.

Rust doesn't use LLVM's libunwind for mingw-w64, it relies on libgcc.

Only if one uses rust-mingw. That's not the only way rustc can be used.

If you use windows-gnu triples Rust will link libgcc_s or libgcc_eh directly unless you modify it's source not to do it: https://github.com/rust-lang/rust/blob/e5fedceabf4e0564231db592b6d1f35e1ca27908/compiler/rustc_target/src/spec/windows_gnu_base.rs#L64