From: Szabolcs Nagy <Szabolcs.Nagy@arm.com> To: Dave P Martin <Dave.Martin@arm.com> Cc: nd <nd@arm.com>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, Will Deacon <Will.Deacon@arm.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Alan Hayward <Alan.Hayward@arm.com> Subject: Re: [PATCH 0/3] arm64/sve: UAPI: Disentangle ptrace.h from sigcontext.h Date: Fri, 14 Dec 2018 19:00:07 +0000 [thread overview] Message-ID: <5e96f169-d77d-63d0-11ba-f59f572b0219@arm.com> (raw) In-Reply-To: <20181214182518.GH3505@e103592.cambridge.arm.com> On 14/12/2018 18:25, Dave Martin wrote: > On Fri, Dec 14, 2018 at 06:13:33PM +0000, Szabolcs Nagy wrote: >> On 11/12/2018 19:26, Dave Martin wrote: >>> This patch refactors the UAPI header definitions for the Arm SVE >>> extension to avoid multiple-definition problems when userspace mixes its >>> own sigcontext.h definitions with the kernel's ptrace.h (which is >>> apparently routine). >>> >>> A common backend header is created to hold common definitions, suitably >>> namespaced, and with an appropriate header guard. >>> >>> See the commit message in patch 3 for further explanation of why this >>> is needed. >>> >>> Because of the non-trivial header guard in the new sve_context.h, patch >>> 1 adds support to headers_install.sh to munge #if defined(_UAPI_FOO) in >>> a similar way to the current handling of #ifndef _UAPI_FOO. >>> >> >> thanks for doing this. >> >> the patches fix the gdb build issue on musl libc with an >> additional gdb patch: >> https://sourceware.org/ml/gdb-patches/2018-12/msg00152.html >> (in userspace i'd expect users relying on signal.h providing >> whatever is in asm/sigcontext.h.) >> >> i think sve_context.h could be made to work with direct include, >> even if that's not useful because there is no public api there. >> (and then you dont need the first patch) > > My general view is that if you want the sigframe types userspace should > usually include <ucontext.h> and refer to mcontext_t. > ucontext.h does not expose the asm/sigcontext.h types in glibc, but it is compatible with the inclusion of asm/sigcontext.h (or signal.h). in musl ucontext.h includes signal.h and signal.h provides the asm/sigcontext.h api with abi compatible definitions. > Because the prototype for sa_sigaction() specifies a void * for the > ucontext argument, I've generally assumed that <signal.h> is not > sufficient to get ucontext_t (or mcontext_t) (but maybe I'm too paranoid > there). http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html "The <signal.h> header shall define the ucontext_t type as a structure that shall include at least the following members: ... mcontext_t uc_mcontext A machine-specific representation of the saved context." so signal.h must define ucontext_t but mcontext_t can be opaque. (it is opaque with posix conform feature tests to avoid namespace pollution, but with _GNU_SOURCE defined all asm/sigcontext.h apis are there and mcontext_t matches struct sigcontext) > > Non-POSIX-flavoured software might include <asm/sigcontext.h> directly. > In glibc/musl libc will that conflict with <signal.h>, or can the two > coexist? if you compile e.g in standard conform mode then i think signal.h and asm/sigcontext.h are compatible. > > Cheers > ---Dave >
WARNING: multiple messages have this Message-ID (diff)
From: Szabolcs Nagy <Szabolcs.Nagy@arm.com> To: Dave P Martin <Dave.Martin@arm.com> Cc: nd <nd@arm.com>, Will Deacon <Will.Deacon@arm.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, Alan Hayward <Alan.Hayward@arm.com> Subject: Re: [PATCH 0/3] arm64/sve: UAPI: Disentangle ptrace.h from sigcontext.h Date: Fri, 14 Dec 2018 19:00:07 +0000 [thread overview] Message-ID: <5e96f169-d77d-63d0-11ba-f59f572b0219@arm.com> (raw) In-Reply-To: <20181214182518.GH3505@e103592.cambridge.arm.com> On 14/12/2018 18:25, Dave Martin wrote: > On Fri, Dec 14, 2018 at 06:13:33PM +0000, Szabolcs Nagy wrote: >> On 11/12/2018 19:26, Dave Martin wrote: >>> This patch refactors the UAPI header definitions for the Arm SVE >>> extension to avoid multiple-definition problems when userspace mixes its >>> own sigcontext.h definitions with the kernel's ptrace.h (which is >>> apparently routine). >>> >>> A common backend header is created to hold common definitions, suitably >>> namespaced, and with an appropriate header guard. >>> >>> See the commit message in patch 3 for further explanation of why this >>> is needed. >>> >>> Because of the non-trivial header guard in the new sve_context.h, patch >>> 1 adds support to headers_install.sh to munge #if defined(_UAPI_FOO) in >>> a similar way to the current handling of #ifndef _UAPI_FOO. >>> >> >> thanks for doing this. >> >> the patches fix the gdb build issue on musl libc with an >> additional gdb patch: >> https://sourceware.org/ml/gdb-patches/2018-12/msg00152.html >> (in userspace i'd expect users relying on signal.h providing >> whatever is in asm/sigcontext.h.) >> >> i think sve_context.h could be made to work with direct include, >> even if that's not useful because there is no public api there. >> (and then you dont need the first patch) > > My general view is that if you want the sigframe types userspace should > usually include <ucontext.h> and refer to mcontext_t. > ucontext.h does not expose the asm/sigcontext.h types in glibc, but it is compatible with the inclusion of asm/sigcontext.h (or signal.h). in musl ucontext.h includes signal.h and signal.h provides the asm/sigcontext.h api with abi compatible definitions. > Because the prototype for sa_sigaction() specifies a void * for the > ucontext argument, I've generally assumed that <signal.h> is not > sufficient to get ucontext_t (or mcontext_t) (but maybe I'm too paranoid > there). http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html "The <signal.h> header shall define the ucontext_t type as a structure that shall include at least the following members: ... mcontext_t uc_mcontext A machine-specific representation of the saved context." so signal.h must define ucontext_t but mcontext_t can be opaque. (it is opaque with posix conform feature tests to avoid namespace pollution, but with _GNU_SOURCE defined all asm/sigcontext.h apis are there and mcontext_t matches struct sigcontext) > > Non-POSIX-flavoured software might include <asm/sigcontext.h> directly. > In glibc/musl libc will that conflict with <signal.h>, or can the two > coexist? if you compile e.g in standard conform mode then i think signal.h and asm/sigcontext.h are compatible. > > Cheers > ---Dave > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2018-12-14 19:00 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-12-11 19:26 [PATCH 0/3] arm64/sve: UAPI: Disentangle ptrace.h from sigcontext.h Dave Martin 2018-12-11 19:26 ` Dave Martin 2018-12-11 19:26 ` [PATCH 1/3] kbuild: install_headers.sh: Strip _UAPI from #if-defined() guards Dave Martin 2018-12-11 19:26 ` Dave Martin 2018-12-11 19:26 ` [PATCH 2/3] arm64/sve: ptrace: Fix SVE_PT_REGS_OFFSET definition Dave Martin 2018-12-11 19:26 ` Dave Martin 2018-12-11 19:26 ` [PATCH 3/3] arm64/sve: Disentangle <uapi/asm/ptrace.h> from <uapi/asm/sigcontext.h> Dave Martin 2018-12-11 19:26 ` Dave Martin 2018-12-15 9:20 ` kbuild test robot 2018-12-15 9:20 ` kbuild test robot 2018-12-18 12:14 ` Dave Martin 2018-12-18 12:14 ` Dave Martin 2018-12-19 15:11 ` Szabolcs Nagy 2018-12-19 15:11 ` Szabolcs Nagy 2018-12-19 15:23 ` Dave Martin 2018-12-19 15:23 ` Dave Martin 2018-12-19 15:26 ` Szabolcs Nagy 2018-12-19 15:26 ` Szabolcs Nagy 2018-12-14 18:13 ` [PATCH 0/3] arm64/sve: UAPI: Disentangle ptrace.h from sigcontext.h Szabolcs Nagy 2018-12-14 18:13 ` Szabolcs Nagy 2018-12-14 18:25 ` Dave Martin 2018-12-14 18:25 ` Dave Martin 2018-12-14 19:00 ` Szabolcs Nagy [this message] 2018-12-14 19:00 ` Szabolcs Nagy 2018-12-14 19:28 ` Dave P Martin 2018-12-14 19:28 ` Dave P Martin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=5e96f169-d77d-63d0-11ba-f59f572b0219@arm.com \ --to=szabolcs.nagy@arm.com \ --cc=Alan.Hayward@arm.com \ --cc=Dave.Martin@arm.com \ --cc=Will.Deacon@arm.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=nd@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.