search

iains / gcc-10-branch

[April 2021] 10.3 plus Darwin additions, initial 10.3 Arm64.
GNU General Public License v2.0
7 stars 2 forks source link

Compiler-RT / Builtins Support? #2

Open emolitor opened 2 years ago

emolitor commented 2 years ago

Minor question but does your support for libc++ include support for using compiler-rt in place of libgcc? What I'm wondering is how far I can go with your libc++ support, can I use the llvm unwinder as well or only use libc++ built against libgcc/libatomic.

iains commented 2 years ago

** the Unwinder should always be coming from /usr/lib/system/libunwind.dylib (Darwin11+ macOS10.7+) /usr/lib/libSystem (on Darwin10.. macOS 10.6) /usr/lib/libgcc_s.1.dylib (on Darwin8 and 9 macOS 10.4 and 5)

If it is coming from the GCC libgcc_s.1, then something is wrong - although DYLD_LIBRARY_PATH can force that on Darwin <= 14 (<= macOS10.10)

If something is not working, please could you make a reproducer and open an issue - of course bugs happen everywhere :)

the compiler builtins are specific to the compiler; of course there are similarities between compilers - intentionally (some of them are also exported from libSystem).

The answer is to general use of libcompiler_rt.a is why would that be any advantage? (I.e. what is the use-case) and you will find that recent improvements in some of the floating point builtins on GCC would mean regressions in tests (or poorer performance in accuracy in real code) until similar improvements appear in libcompiler_rt or libSystem.

iains commented 2 years ago

additional - note that GCC uses emulated TLS - and the support for that comes from GCC's libgcc_s.1.dylib - the implementation of the thread support is GCC-specific so that this would need to be handled for any dependent lib that used it.

** The intended use-case for the libc++ support, is to allow you to use the /usr/lib/libc++.dylib (and libc++-abi.dylib). on Darwin systems where that is the default c++ library - so that when linking with system libraries and frameworks there is only one libc++ in use.....

... If you are building libc++ too (on a system that already has them) then you will have to be very careful to use the system libc++abi .. (or you could end up allocating some object in one, and trying to destroy it in another)...

if you're working on an older Darwin (that doesn't have libc++, i.e darwin8, 9, 10) then you will need to get the abi library and unwinder by linking the build of libc++ with /usr/libstdc++.6.dylib ... such configurations are quite complex - and need patches to the libc++ build ... (there might be some in my llvm-7.1.1 tree)

note that you then (on these older systems) have 2 libc++ implementations in use - because system libraries and frameworks will be linked against /usr/lib/libstdc++.6.dylib.

it can be made to work, but it is definitely non-trivial and means that your distribution has to be built from the compiler upwards so that everything gets the intended libs.

emolitor commented 2 years ago

Thanks, I'll try to submit patches and repro cases for anything I find that doesn't work.

On Thu, 23 Sep 2021, 9:42 am iains, @.***> wrote:

additional - note that GCC uses emulated TLS - and the support for that comes from GCC's libgcc_s.1.dylib - the implementation of the thread support is GCC-specific so that this would need to be handled for any dependent lib that used it.

** The intended use-case for the libc++ support, is to allow you to use the /usr/lib/libc++.dylib (and libc++-abi.dylib). on Darwin systems where that is the default c++ library - so that when linking with system libraries and frameworks there is only one libc++ in use.....

... If you are building libc++ too (on a system that already has them) then you will have to be very careful to use the system libc++abi .. (or you could end up allocating some object in one, and trying to destroy it in another)...

if you're working on an older Darwin (that doesn't have libc++, i.e darwin8, 9, 10) then you will need to get the abi library and unwinder by linking the build of libc++ with /usr/libstdc++.6.dylib ... such configurations are quite complex - and need patches to the libc++ build ... (there might be some in my llvm-7.1.1 tree)

note that you then (on these older systems) have 2 libc++ implementations in use - because system libraries and frameworks will be linked against /usr/lib/libstdc++.6.dylib.

it can be made to work, but it is definitely non-trivial and means that your distribution has to be built from the compiler upwards so that everything gets the intended libs.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/iains/gcc-10-branch/issues/2#issuecomment-925880776, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAECQN5R62XBUQVYZHZJO63UDM4D3ANCNFSM5ETZVSNA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.