Message ID | c3b4c41c-b4eb-7d10-6191-8e80d1bfc806@arm.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 37542 invoked by alias); 14 Dec 2018 18:00:49 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 37511 invoked by uid 89); 14 Dec 2018 18:00:47 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 spammy=H*c:HHH X-HELO: EUR01-HE1-obe.outbound.protection.outlook.com Received: from mail-eopbgr130041.outbound.protection.outlook.com (HELO EUR01-HE1-obe.outbound.protection.outlook.com) (40.107.13.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 14 Dec 2018 18:00:45 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Vi+hml5zBayBpFImruz09JAADHjlqWKkXsWYf7TI1Ls=; b=EYl4CzgL8ZmXbGVOf/kMIXeBeFQilHJmGfTRWFXg5eG3NA2bL1DY69Ag6XY6wpCEKajcAMmvDp9a8mpJlKkWgWU0Xc8+2Yt7PRKTUv8H10si1t4U3yQYIlbraWaNbGTWM/E5hRExP0Sp9eZSk4+cjtbUVmXaG5Zx3llurF7QHbs= Received: from VI1PR08MB4223.eurprd08.prod.outlook.com (20.178.13.96) by VI1PR08MB3583.eurprd08.prod.outlook.com (20.177.61.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1404.19; Fri, 14 Dec 2018 18:00:41 +0000 Received: from VI1PR08MB4223.eurprd08.prod.outlook.com ([fe80::b9e5:694c:a7d1:d37b]) by VI1PR08MB4223.eurprd08.prod.outlook.com ([fe80::b9e5:694c:a7d1:d37b%4]) with mapi id 15.20.1404.026; Fri, 14 Dec 2018 18:00:41 +0000 From: Szabolcs Nagy <Szabolcs.Nagy@arm.com> To: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org> CC: nd <nd@arm.com>, Alan Hayward <Alan.Hayward@arm.com> Subject: [PATCH] AArch64: Fix the gdb build with musl libc Date: Fri, 14 Dec 2018 18:00:41 +0000 Message-ID: <c3b4c41c-b4eb-7d10-6191-8e80d1bfc806@arm.com> user-agent: Mozilla/5.0 (X11; Linux aarch64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs.Nagy@arm.com; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) Content-Type: multipart/mixed; boundary="_002_c3b4c41cb4eb7d1061918e80d1bfc806armcom_" MIME-Version: 1.0 X-IsSubscribed: yes |
Commit Message
Szabolcs Nagy
Dec. 14, 2018, 6 p.m. UTC
Including asm/sigcontext.h together with libc headers is not valid. In general linux headers may not work with libc headers, so mixing them should be avoided, especially when the linux header defines types that are also exposed in libc headers. In case of asm/sigcontext.h glibc happens to work because glibc signal.h directly includes it, but e.g. in musl libc signal.h replicates the sigcontext.h definitions in an abi compatible way which are in conflict with the linux definitions when both headers are included. Since old linux headers or old libc headers may not have the necessary definitions, gdb has to replicate the definitions it relies on anyway. Which is fine since all definitions must be ABI stable. For linux apis that are not available via libc headers, replicating the definitions in gdb is the most reliable way to use them. Note: asm/ptrace.h includes asm/sigcontext.h in some versions of linux headers, which is just as problematic and should be fixed in linux. gdb/ChangeLog: 2018-12-14 Szabolcs Nagy <szabolcs.nagy@arm.com> * nat/aarch64-sve-linux-ptrace.h: Include signal.h instead of asm/sigcontext.h.
Comments
> On 14 Dec 2018, at 18:00, Szabolcs Nagy <Szabolcs.Nagy@arm.com> wrote: > > Including asm/sigcontext.h together with libc headers is not valid. In > general linux headers may not work with libc headers, so mixing them > should be avoided, especially when the linux header defines types that > are also exposed in libc headers. > > In case of asm/sigcontext.h glibc happens to work because glibc signal.h > directly includes it, but e.g. in musl libc signal.h replicates the > sigcontext.h definitions in an abi compatible way which are in conflict > with the linux definitions when both headers are included. > > Since old linux headers or old libc headers may not have the necessary > definitions, gdb has to replicate the definitions it relies on anyway. > Which is fine since all definitions must be ABI stable. For linux apis > that are not available via libc headers, replicating the definitions in > gdb is the most reliable way to use them. > > Note: asm/ptrace.h includes asm/sigcontext.h in some versions of linux > headers, which is just as problematic and should be fixed in linux. I’m assuming that this fix still works with the 3 part "arm64/sve: UAPI: Disentangle ptrace.h from sigcontext.h” kernel patch from Dave Martin? If so, then LGTM. > > gdb/ChangeLog: > > 2018-12-14 Szabolcs Nagy <szabolcs.nagy@arm.com> > > * nat/aarch64-sve-linux-ptrace.h: Include signal.h instead of > asm/sigcontext.h. > <sig.diff>
On 17/12/2018 10:21, Alan Hayward wrote: >> On 14 Dec 2018, at 18:00, Szabolcs Nagy <Szabolcs.Nagy@arm.com> wrote: >> >> Including asm/sigcontext.h together with libc headers is not valid. In >> general linux headers may not work with libc headers, so mixing them >> should be avoided, especially when the linux header defines types that >> are also exposed in libc headers. >> >> In case of asm/sigcontext.h glibc happens to work because glibc signal.h >> directly includes it, but e.g. in musl libc signal.h replicates the >> sigcontext.h definitions in an abi compatible way which are in conflict >> with the linux definitions when both headers are included. >> >> Since old linux headers or old libc headers may not have the necessary >> definitions, gdb has to replicate the definitions it relies on anyway. >> Which is fine since all definitions must be ABI stable. For linux apis >> that are not available via libc headers, replicating the definitions in >> gdb is the most reliable way to use them. >> >> Note: asm/ptrace.h includes asm/sigcontext.h in some versions of linux >> headers, which is just as problematic and should be fixed in linux. > > I’m assuming that this fix still works with the 3 part "arm64/sve: UAPI: > Disentangle ptrace.h from sigcontext.h” kernel patch from Dave Martin? > > If so, then LGTM. yes, committed. thanks. >> >> gdb/ChangeLog: >> >> 2018-12-14 Szabolcs Nagy <szabolcs.nagy@arm.com> >> >> * nat/aarch64-sve-linux-ptrace.h: Include signal.h instead of >> asm/sigcontext.h. >> <sig.diff> >
diff --git a/gdb/nat/aarch64-sve-linux-ptrace.h b/gdb/nat/aarch64-sve-linux-ptrace.h index 029e753ffe..172ae39432 100644 --- a/gdb/nat/aarch64-sve-linux-ptrace.h +++ b/gdb/nat/aarch64-sve-linux-ptrace.h @@ -20,7 +20,7 @@ #ifndef AARCH64_SVE_LINUX_PTRACE_H #define AARCH64_SVE_LINUX_PTRACE_H -#include <asm/sigcontext.h> +#include <signal.h> #include <sys/utsname.h> #include <sys/ptrace.h> #include <asm/ptrace.h>