This is the mail archive of the
libc-alpha@sourceware.org
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.2.20.1706201753090.29540@digraph.polyomino.org.uk> <59526EF4.4050609@arm.com> <alpine.DEB.2.20.1706271505100.18823@digraph.polyomino.org.uk>
- 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.