Opened 10 months ago
Closed 6 months ago
#18825 closed bug (fixed)
Exception handling (call frame generation) broken on GCC 13 x86
Reported by: | waddlesplash | Owned by: | nielx |
---|---|---|---|
Priority: | blocker | Milestone: | R1/beta5 |
Component: | Build System | Version: | R1/beta4 |
Keywords: | Cc: | nielx | |
Blocked By: | Blocking: | ||
Platform: | All |
Description
64-bit works, 32-bit doesn't.
As seen with Koder and other applications. Example difference in generated assembly: https://github.com/KapiX/Koder/issues/147#issuecomment-1828476677
Change History (5)
follow-up: 2 comment:1 by , 10 months ago
comment:2 by , 10 months ago
Replying to nielx:
What is the exact case? I am scrolling to the comments, and it seems like it depends on a shared library compiled with an older GCC, which is then linked to an executable in a newer GCC? And if the exception is in the library, it does not get thrown?
The test case is explained in this comment: https://github.com/KapiX/Koder/issues/147#issuecomment-1828476677
The exception gets thrown, but it does not get caught.
comment:3 by , 7 months ago
Owner: | changed from | to
---|---|
Status: | new → in-progress |
I am testing binutils 2.42 and GCC 14.1 to see if that has any material effect on the issue.
comment:4 by , 6 months ago
The issue itself is fixed at HaikuPorts for GCC13. The patch is applied in btrev43215.
Please note that any binaries built with GCC13 before today could possibly expose the same problem as yaml_cpp libs.
I don't manage to access the vendor-gcc branch of the buildtools repo, to apply the upgrade for gcc 13.3, then a build fix patch for it. COuld someone help?
comment:5 by , 6 months ago
Resolution: | → fixed |
---|---|
Status: | in-progress → closed |
Newer GCC merged in btrev43216 and buildtools rebuilt for the buildbots. So this is now fixed.
What is the exact case? I am scrolling to the comments, and it seems like it depends on a shared library compiled with an older GCC, which is then linked to an executable in a newer GCC? And if the exception is in the library, it does not get thrown?