On Tue, Feb 18, 2025 at 07:17:24PM +0100, Uros Bizjak wrote:
> On Mon, Feb 17, 2025 at 6:19 PM Roman Kagan <rka...@amazon.de> 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 <ander...@codepoet.org>
Date: Fri Mar 1 20:46:26 2002 +0000
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 <vap...@gentoo.org>
Date: Tue Feb 15 01:27:10 2005 +0000
headers for x86_64
bionic:
libc/include/sys/ucontext.h
commit e61d106008f7d77fa1c0de43ac27311320225135
Author: Pavel Chupin <pavel.v.chu...@intel.com>
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 <pavel.v.chu...@intel.com>
commit 677a07cb9a3f5964e9ead4d37b9f775d971c61e0
Author: Elliott Hughes <e...@google.com>
Date: Wed Jan 29 16:46:00 2014 -0800
Add x86 <sys/ucontext.h>.
Change-Id: I43e72604f7a932f134733b78094b577415a5edb7
musl:
arch/i386/bits/signal.h
arch/x86_64/bits/signal.h
include/ucontext.h
commit ad2fe25041622b6cf426b0f98af0e52c2c9727f6
Author: Rich Felker <dal...@aerifal.cx>
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.
