[PATCH] libgcc: i386/linux-unwind.h: always rely on sys/ucontext.h
When gcc is built for x86_64-linux-musl target, stack unwinding from within signal handler stops at the innermost signal frame. The reason for this behaviro is that the signal trampoline is not accompanied with appropiate CFI directives, and the fallback path in libgcc to recognize it by the code sequence is only enabled for glibc except 2.0. The latter is motivated by the lack of sys/ucontext.h in that glibc version. Given that all relevant libc-s ship sys/ucontext.h for over a decade, and that other arches aren't shy of unconditionally using it, follow suit and remove the preprocessor condition, too. Signed-off-by: Roman Kagan --- libgcc/config/i386/linux-unwind.h | 7 --- 1 file changed, 7 deletions(-) diff --git a/libgcc/config/i386/linux-unwind.h b/libgcc/config/i386/linux-unwind.h index fe316ee02cf2..8f37642bbf55 100644 --- a/libgcc/config/i386/linux-unwind.h +++ b/libgcc/config/i386/linux-unwind.h @@ -33,12 +33,6 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see #ifndef inhibit_libc -/* There's no sys/ucontext.h for glibc 2.0, so no - signal-turned-exceptions for them. There's also no configure-run for - the target, so we can't check on (e.g.) HAVE_SYS_UCONTEXT_H. Using the - target libc version macro should be enough. */ -#if defined __GLIBC__ && !(__GLIBC__ == 2 && __GLIBC_MINOR__ == 0) - #include #include @@ -199,5 +193,4 @@ x86_frob_update_context (struct _Unwind_Context *context, } #endif /* ifdef __x86_64__ */ -#endif /* not glibc 2.0 */ #endif /* ifdef inhibit_libc */ -- 2.47.1
Re: [PATCH] libgcc: i386/linux-unwind.h: always rely on sys/ucontext.h
On Thu, Jan 02, 2025 at 04:32:17PM +0100, Roman Kagan wrote: > When gcc is built for x86_64-linux-musl target, stack unwinding from > within signal handler stops at the innermost signal frame. The reason > for this behaviro is that the signal trampoline is not accompanied with > appropiate CFI directives, and the fallback path in libgcc to recognize > it by the code sequence is only enabled for glibc except 2.0. The > latter is motivated by the lack of sys/ucontext.h in that glibc version. > > Given that all relevant libc-s ship sys/ucontext.h for over a decade, > and that other arches aren't shy of unconditionally using it, follow > suit and remove the preprocessor condition, too. > > Signed-off-by: Roman Kagan > --- > libgcc/config/i386/linux-unwind.h | 7 --- > 1 file changed, 7 deletions(-) > > diff --git a/libgcc/config/i386/linux-unwind.h > b/libgcc/config/i386/linux-unwind.h > index fe316ee02cf2..8f37642bbf55 100644 > --- a/libgcc/config/i386/linux-unwind.h > +++ b/libgcc/config/i386/linux-unwind.h > @@ -33,12 +33,6 @@ see the files COPYING3 and COPYING.RUNTIME respectively. > If not, see > > #ifndef inhibit_libc > > -/* There's no sys/ucontext.h for glibc 2.0, so no > - signal-turned-exceptions for them. There's also no configure-run for > - the target, so we can't check on (e.g.) HAVE_SYS_UCONTEXT_H. Using the > - target libc version macro should be enough. */ > -#if defined __GLIBC__ && !(__GLIBC__ == 2 && __GLIBC_MINOR__ == 0) > - > #include > #include > > @@ -199,5 +193,4 @@ x86_frob_update_context (struct _Unwind_Context *context, > } > > #endif /* ifdef __x86_64__ */ > -#endif /* not glibc 2.0 */ > #endif /* ifdef inhibit_libc */ Ping? Roman.
Re: [PATCH] libgcc: i386/linux-unwind.h: always rely on sys/ucontext.h
On Tue, Feb 18, 2025 at 07:17:24PM +0100, Uros Bizjak wrote: > On Mon, Feb 17, 2025 at 6:19 PM Roman Kagan wrote: > > > > On Thu, Jan 02, 2025 at 04:32:17PM +0100, Roman Kagan wrote: > > > When gcc is built for x86_64-linux-musl target, stack unwinding from > > > within signal handler stops at the innermost signal frame. The reason > > > for this behaviro is that the signal trampoline is not accompanied with > > > appropiate CFI directives, and the fallback path in libgcc to recognize > > > it by the code sequence is only enabled for glibc except 2.0. The > > > latter is motivated by the lack of sys/ucontext.h in that glibc version. > > > > > > Given that all relevant libc-s ship sys/ucontext.h for over a decade, > > > and that other arches aren't shy of unconditionally using it, follow > > > suit and remove the preprocessor condition, too. > > "Relevant libc"-s for x86 linux are LIBC_GLIBC, LIBC_UCLIBC, > LIBC_BIONIC and LIBC_MUSL. As far as glibc is concerned, the latest > glibc 2.0.x version was released in 1997 [1], so I guess we can remove > the condition for version 2.0. Based on your claim, the other > mentioned libcs also provide the required header for a long time. Ah, good point, for completeness I should've supplied evidence from their respective git repos, here you go: uclibc(-ng): libc/sysdeps/linux/i386/sys/ucontext.h commit 9cee42f10dbc5b33866ff137b926a74abd7c1a5b Author: Eric Andersen Date: Fri Mar 1 20:46:26 2002 + Major rework of the include files to eliminate redundancy and to better support each arch. This is a really big patch... -Erik libc/sysdeps/linux/i386/sys/ucontext.h commit 1fef64b22811709b2e640d341237bce1c8081203 Author: Mike Frysinger Date: Tue Feb 15 01:27:10 2005 + headers for x86_64 bionic: libc/include/sys/ucontext.h commit e61d106008f7d77fa1c0de43ac27311320225135 Author: Pavel Chupin Date: Mon Jan 27 17:56:43 2014 +0400 Add x86_64 ucontext.h for better compatibility As suggested here: https://android-review.googlesource.com/#/c/71267/ it may be used for x86_64 libunwind enabling. Change-Id: I21623261a48ea7099e030d33932556e294d226ff Signed-off-by: Pavel Chupin commit 677a07cb9a3f5964e9ead4d37b9f775d971c61e0 Author: Elliott Hughes Date: Wed Jan 29 16:46:00 2014 -0800 Add x86 . Change-Id: I43e72604f7a932f134733b78094b577415a5edb7 musl: arch/i386/bits/signal.h arch/x86_64/bits/signal.h include/ucontext.h commit ad2fe25041622b6cf426b0f98af0e52c2c9727f6 Author: Rich Felker Date: Fri Feb 18 22:03:03 2011 -0500 support the ugly and deprecated ucontext and sigcontext header stuff... only the structures, not the functions from ucontext.h, are supported at this point. the main goal of this commit is to make modern gcc with dwarf2 unwinding build without errors. honestly, it probably doesn't matter how we define these as long as they have members with the right names to prevent errors while compiling libgcc. the only time they will be used is for propagating exceptions across signal-handler boundaries, which invokes undefined behavior anyway. but as-is, they're probably correct and may be useful to various low-level applications dealing with virtualization, jit code generation, and so on... > I have no objection to the patch, but I think that this patch is a bit > late for gcc-15 and should be committed early in the gcc-16 > development cycle. But let's hear release managers (CC'd). I gather that GCC doesn't have "cc: stable" process similar to Linux, does it? Fine by me anyway. If it lands in GCC repo I'll at least be able to poke at some downstream maintainers with a link to cherry-pick. Thanks, Roman.
Re: [PATCH] libgcc: i386/linux-unwind.h: always rely on sys/ucontext.h
On Tue, Feb 18, 2025 at 08:23:15PM +0100, Richard Biener wrote: > > Am 18.02.2025 um 20:07 schrieb Roman Kagan : > > On Tue, Feb 18, 2025 at 07:17:24PM +0100, Uros Bizjak wrote: > >>> On Mon, Feb 17, 2025 at 6:19 PM Roman Kagan wrote: > >>> On Thu, Jan 02, 2025 at 04:32:17PM +0100, Roman Kagan wrote: > >>>> When gcc is built for x86_64-linux-musl target, stack unwinding from > >>>> within signal handler stops at the innermost signal frame. The reason > >>>> for this behaviro is that the signal trampoline is not accompanied with > >>>> appropiate CFI directives, and the fallback path in libgcc to recognize > >>>> it by the code sequence is only enabled for glibc except 2.0. The > >>>> latter is motivated by the lack of sys/ucontext.h in that glibc version. > >>>> > >>>> Given that all relevant libc-s ship sys/ucontext.h for over a decade, > >>>> and that other arches aren't shy of unconditionally using it, follow > >>>> suit and remove the preprocessor condition, too. > >> > >> "Relevant libc"-s for x86 linux are LIBC_GLIBC, LIBC_UCLIBC, > >> LIBC_BIONIC and LIBC_MUSL. As far as glibc is concerned, the latest > >> glibc 2.0.x version was released in 1997 [1], so I guess we can remove > >> the condition for version 2.0. Based on your claim, the other > >> mentioned libcs also provide the required header for a long time. > > [...] You should possibly see to add the missing CFI directives on > your system? Indeed. Out of the four libcs listed, two -- glibc and bionic -- have CFI in their signal trampolines, the other two -- musl and uClibc-ng -- don't. Musl, which I happen to use right now, is not very friendly with unwinding in general: it passes -fno-unwind-tables -fno-asynchronous-unwind-tables to the compiler, it has (almost) no support for CFI in assembly sources, and so on. So patching libgcc_eh to use the fallback for signal frames on x86 as it does on other arches looked like a reasonable start, but yes, I still have work to do to make unwinding work through library functions too. Thanks, Roman.
