This is the mail archive of the
mailing list for the glibc project.
Re: Fix mcontext_t sigcontext namespace (bug 21457)
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: nd at arm dot com, libc-alpha at sourceware dot org, Florian Weimer <fweimer at redhat dot com>
- Date: Tue, 27 Jun 2017 16:27:53 +0100
- Subject: Re: Fix mcontext_t sigcontext namespace (bug 21457)
- Authentication-results: sourceware.org; auth=none
- Authentication-results: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=arm.com;
- Nodisclaimer: True
- References: <alpine.DEB.firstname.lastname@example.org> <59526EF4.email@example.com> <alpine.DEB.firstname.lastname@example.org>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On 27/06/17 16:11, Joseph Myers wrote:
> On Tue, 27 Jun 2017, Szabolcs Nagy wrote:
>>> diff --git a/sysdeps/unix/sysv/linux/aarch64/sys/ucontext.h b/sysdeps/unix/sysv/linux/aarch64/sys/ucontext.h
>>> index 4f602fc..90d0c42 100644
>>> --- a/sysdeps/unix/sysv/linux/aarch64/sys/ucontext.h
>>> +++ b/sysdeps/unix/sysv/linux/aarch64/sys/ucontext.h
>>> @@ -24,10 +24,15 @@
>>> #include <features.h>
>>> #include <bits/types/sigset_t.h>
>>> -#include <bits/sigcontext.h>
>> this may break software that rely on declarations from
>> asm/sigcontext.h to be visible in sys/ucontext.h (e.g.
>> struct fpsimd_context ?), but i don't know if this is
>> actually the case.
> They can of course include <signal.h> (or <asm/sigcontext.h> directly).
> It's possible to keep the include, conditioned on __USE_MISC, just not
> clear that's worthwhile.
i didn't know signal.h already includes sigcontext.h,
then the change is ok.
>> i find the c++ abi break problematic.
>> i would not expect mcontext_t to be common argument
>> in c++ code, but it's a moderately dangerous change,
>> while the status quo is not too bad.
> For some previous patches in this series, changing stack_t and ucontext_t,
> Florian checked there were no affected mangled names in Fedora, as
> evidence for such problems being rare. Such a check might be worthwhile
> here (remembering that what is being looked for is architecture-specific,
> but on x86_64 / x86 the mangled name is already mcontext_t and would not
> change because there aren't namespace issues there).
Florian, if you can check, then please do.