The state of PPC exception handling

[evanmiller]

A couple of projects built using MacPorts GCC 7.5 on 10.4.11 / PPC have run-time issues with C++ exception handling. An exception is thrown and there is an infinite loop of some kind before a handler is chosen or invoked. The most comprehensive report I have can be found in this thread:

kcat/openal-soft#610

In the above-linked thread, @kencu noted that the toolchain might be the culprit. I have seen a very similar issue attempting to run mrustc on the same machine, and so the toolchain is very much a "program of interest" in my investigation.

If this issue is already well-known, I'd like to get some clarity or read more about it. Could this be a GCC 7.5 issue – or is it possibly an issue with how MacPorts configures and installs GCC? Does these hangs affect 10.4 only (where I am seeing them) or 10.5 also? Are there compiler options that I could try to circumvent the issue? I will note that I am unable to reproduce the issue with simple "Hello, world" type programs.

As a workaround, I tried to bootstrap a compiler with --enable-sjlj-exceptions so that I could at least run the code with a parallel SJLJ C++ run-time. These efforts failed; the bootstrap process seemed to have a hard time keeping straight which components were compiled with SJLJ and which were not, and my few attempts at compilation ended with undefined symbols related to unwinding.

Any pointers, links, or explanations would be appreciated.

[kencu]

@iains will comment directly, but I believe the broken dylib he replaces with a current version is /usr/lib/libgcc_s.1.dylib, where the unwinding code lives.

I have never tried it, myself.

[kencu]

for example, this is the one from libgcc11 on 10.14, right in front of me here:

$ nm -a /opt/local/lib/libgcc/libgcc_s.1.dylib
000000000000accb T __Unwind_Backtrace
000000000000acb7 T __Unwind_DeleteException
000000000000a7d6 T __Unwind_FindEnclosingFunction
000000000000bcae T __Unwind_Find_FDE
000000000000aa45 T __Unwind_ForcedUnwind
000000000000a759 T __Unwind_GetCFA
000000000000a7f6 T __Unwind_GetDataRelBase
0000000000009c57 T __Unwind_GetGR
000000000000a79e T __Unwind_GetIP
000000000000a7a6 T __Unwind_GetIPInfo
000000000000a7c6 T __Unwind_GetLanguageSpecificData
000000000000a7ce T __Unwind_GetRegionStart
000000000000a7fe T __Unwind_GetTextRelBase
000000000000a8f6 T __Unwind_RaiseException
000000000000ab19 T __Unwind_Resume
000000000000abde T __Unwind_Resume_or_Rethrow
000000000000a761 T __Unwind_SetGR
000000000000a7be T __Unwind_SetIP
... etc ...

[iains]

SjLj will not work - Darwin from 10.4 onwards uses the "zero cost" [DWARF-based] unwind, essentially sjlj is an invalid configuration.

Because unwinders have global state about a process (and need to be able to find the frames for any function), there can only be one unwinder in a process. So that it is essential that the unwinder used for system libraries/frameworks is the same one as used in the application code.

I know of two bugs (which are fixed on new GCC versions).

1/ That the compiler used to generate code that the /usr/lib/libgcc_s unwinder did understand - PR48-097/PR44107 - that is fixed back to GCC-9 and I have back ports available for gcc-8 and 7.

2/ When DYLD_LIBRARY_PATH is used (on versions of Darwin that support it) and that path includes the installation of the compiler's libgcc_s, the unwinder from the compiler's libgcc_s can be picked up unintentionally.

• I have fixed this (where possible) on master, and back-ports are pending (and I will have them back to gcc-7 at least).

[iains]

I'd like to know what causes so many versions to be required. There has only been one case of a symbol being intentionally removed (since it should never have been there in the first place) - but the only user of that symbol was libjava - and that is not relevant after GCC6 - plus the underlying issue was also fixed.

So I'm not quite sure why GCC-12's libgcc_s.1.dylib (specially made to be backward-compatible) does not work for previous GCC >= 7 (with the proper patches applied to gcc-6 libjava it should also work for <= GCC 6).

If not, then please please file bugs so that we can fix stuff instead of having this hard-to-understand set of workarounds.

[kencu]

There are good reasons that every gcc compiler does not use it's own copy of libgcc, but the main one is that if there is one libgcc shared by all, then the objects are all identical and shareable and there is only one copy of them in the address space of all the executables built by any version of gcc.

Regarding why so many libgcc versions, it works like this.

Build libgcc11. Then build libgcc5. If there are any libraries in libgcc5 that are not in libgcc11, we need to install those.
Rinse and repeat for libgcc 6,7,8,9, and 10.

And soon libgcc12 will be it, and libgcc11 will become a contributor of only what exists in libgcc11 that does not exist in libgcc12.

This library plan will probably never change, by they way, for MacPorts. It has been the way for 15 years now, and it works extremely well, although it challenges the gcc maintainers and updaters to stay sharp.

And updating the baseline libgcc is not a super-trivial exercise of seeing if it builds on one system like LeopardPPC and pushing it through ;> No, no, no -- you have to do it right, for all systems, and make sure it works on all of them.

[kencu]

I suppose I should clarify a bit. If for example you have no need (or ability) for say gcc5 to build and run on a given system like Monterey, then you don't need to care about building or installing libgcc5's "missing libraries" (the ones that are not in libgcc11) on Monterey.

[barracuda156]

And updating the baseline libgcc is not a super-trivial exercise of seeing if it builds on one system like LeopardPPC and pushing it through ;> No, no, no -- you have to do it right, for all systems, and make sure it works on all of them.

@kencu In a case I caused a misunderstanding, I do not intend to say that Macports should move to libgcc11 across the board because it builds and works on my systems locally. My general idea is that everything is more hard and/or broken for PPC, so once even PPC works, the rest follows, but essentially my point is just to state the evidence and leave any decisive conclusions to more knowledgeable people like you and others.

[kencu]

I think if MacPorts moves the 10.4/10.5 Intel and PPC systems to libgcc11, it will probably be you and Evan who will actually do the work. I'm just trying to help you get there smoothly by seeing just what has to happen.

[kencu]

we might need an “exactly how…” for 10.4 through 10.6, when/if you get a moment for that…

[iains]

"exactly how" is going to depend on which version of GCC you are using - if 7.5 then it will definitely need back-ports of the relevant patches, I will try to identify them later in the week/at the weekend.

[barracuda156]

"exactly how" is going to depend on which version of GCC you are using - if 7.5 then it will definitely need back-ports of the relevant patches, I will try to identify them later in the week/at the weekend.

@iains Does gcc10 build on Tiger for you btw? That is perhaps the only system where gcc7 remains relevant so far.

[iains]

"exactly how" is going to depend on which version of GCC you are using - if 7.5 then it will definitely need back-ports of the relevant patches, I will try to identify them later in the week/at the weekend.

@iains Does gcc10 build on Tiger for you btw? That is perhaps the only system where gcc7 remains relevant so far.

I've built a cross and native cross ->darwin8 on darwin9 (one or two small additions to the branch to make before it's released). I don't currently have any darwin8 systems running, and the PPC one would take several days to bootstrap and test. NOTE: you will almost certainly need to build ld64-85.2.1 (and maybe cctools) from Xcode 3.1.4 to get darwin8 working decently.

I might be able to spin up an i686 darwin8 system, but not likely to have time to do the ppc one.

[iains]

update (as expected, but checked anyway):

1. 10.4 is not buildable with gcc-4.0.1 (failure in C++)
2. 10.4 is not buildable with ld64-62.1 (problems with mdynamic-no-pic)

my 22 year old 500M G4 (PowerMac AGP) takes ≈ 2 days to bootstrap, so this will take a week more to answer.
15 year old core duo is a lot quicker.

I've been checking with gcc-7.5 as the bootstrap compiler (the results on i686 are "ok ish" similar to i686-darwin9, with a few more Ada fails).

---

Next: using gcc-4.2.1 (5666.3) + ld64-85.2.1 + cctools 698 [i.e the 'bootstrap' arrangement for Tiger/Darwin8/10.4]

... don't hold your breath .. this takes a loooooooooong time on this old hardware.

[iains]

For the 10.4 preview, this is all OK for native cases (darwin8 and darwin9).
There are some excess fails for Rosetta on 10.6.8 related to exceptions with vector types.

[evanmiller]

Small update: The unwinder patch for GCC9 also applies cleanly to GCC7.5. Compiling now...

[evanmiller]

Just to provide an update, many moons later. Although the patch applied cleanly to GCC7.5, the build never completed (appeared to hang for days). So the issue remains unresolved.

[barracuda156]

Just to provide an update, many moons later. Although the patch applied cleanly to GCC7.5, the build never completed (appeared to hang for days). So the issue remains unresolved.

Interesting. It follows from what Iain says there that the patch is applicable to gcc5. But on gcc7 it apparently doesn’t work.