> Am 18.02.2025 um 20:07 schrieb Roman Kagan <rka...@amazon.de>:
>
> 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).
It’s fine for 15, or rather I’m leaving it for you to decide.
> I gather that GCC doesn't have "cc: stable" process similar to Linux,
> does it?
Patches can be back ported to release branches if they fix regressions or
important bugs. You should possibly see to add the missing CFI directives on
your system?
Richard
>
> 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.
