From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 23512 invoked from network); 7 Nov 2021 07:15:46 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 7 Nov 2021 07:15:46 -0000 Received: (qmail 31976 invoked by uid 550); 7 Nov 2021 07:15:42 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 31944 invoked from network); 7 Nov 2021 07:15:41 -0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FWjlL6QUH9wGfWV4ZZg0Ko9adT5SSBWJZKmcGK0DTaopczWE81dZeNIsh/ew6/SFTQijyatN6kw33eNULsQ+JosLqQxZsnf7Zj5V1N/fNuOxpMtYGxubx47BRRjqXnRoT3PLUnz5FWC0yXFg+LKy7Yb8sbpx1b0ynrXHldAVa1MVWXziRMcWV//+4NQw4wEb6ORhPRN6Tsez0qjC4zg+T156fmf83fUz3xbHl0q2oq5AgfIojgfZrzHBlIQwKD+EnLyaFClpjzoytD8UnOzwJBKXFExYr09CLEAEw7RkGJM9EQOu9nngD77BwG7a4rPOh9U9GGAwJh8bYJoM+CBDMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rVhjXStOokojamT+IakBX+lF8RHjxuf81hsYoezYqnI=; b=h0iRKA0ZgF5YulFjVkUyrnAbkGY67XbL7KHJT1EsP18k3tXe9HJQafqgFlQIrVLPO3eQZ/cwY+CuVG0qbS7F2TgFSOtC0SFWhngH2kca/wZSwG27PqgfqNpg3rcvtdIzJcQNSgpaauDKLFRWe80mDyA+kmJIuEQs/vpJqusA+UqT2tVllJVXV/u2G9enUe8BFd/P6Rvalnwo21QveXPc0yp9NDgxS1sdnBJqEJjIyexUwLMZeAJt7+sERDffrBgN5kfzxuKk4rmsSuev9GGSpTHVhRjuZrT9mFvXC4sUR3Cena6irH3KHRyosS4vgcPvZDBNUkaUgPkPUD23w+b6vg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none X-Gm-Message-State: AOAM532PtDub9lO/0djLXzSv/WVOCi/3Lj5zJQlL3H8eYTBqFNqZFXud rObFp1xE2c11CkQVVA3j3+mFEQtEpZUJ5LG4pkE= X-Google-Smtp-Source: ABdhPJxRoOHKYmXq8Tm2Qdmp5I2mCrBSw/l9Ka3PPOb5dbft0/blJ16JgV3fgWXegQzzBVOsW6+ry0sXlveL1uAQDGE= X-Received: by 2002:a05:6122:da0:: with SMTP id bc32mr86369739vkb.4.1636268890436; Sun, 07 Nov 2021 00:08:10 -0700 (PDT) References: <20210818225222.81919-1-galibert@pobox.com> <20210819004903.GN13220@brightrain.aerifal.cx> <878s0y2d4r.fsf@oldenburg.str.redhat.com> <20210819133841.GP13220@brightrain.aerifal.cx> <20210820064602.GJ37904@port70.net> In-Reply-To: <20210820064602.GJ37904@port70.net> From: Fangrui Song Date: Sun, 7 Nov 2021 00:07:59 -0700 X-Gmail-Original-Message-ID: Message-ID: To: musl@lists.openwall.com, Rich Felker , Florian Weimer , Olivier Galibert Content-Type: text/plain; charset="UTF-8" X-TMN: [dyXWJH6Yur5YlEx70mG9HJ1nsNRx2zhh] X-ClientProxiedBy: CO2PR05CA0085.namprd05.prod.outlook.com (2603:10b6:104:1::11) To MWHPR1201MB0110.namprd12.prod.outlook.com (2603:10b6:301:56::8) X-Microsoft-Original-Message-ID: MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8286e0d7-6648-4732-ac35-08d9a1be521b X-MS-TrafficTypeDiagnostic: MWHPR1201MB0112: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 0om8jsghoihB0mYsob+NVhaFSkJmUCMtZ3FlGayhLdfnf8x+PjaJWOngfRpqF+655ifsV9ny5Lc4g6TYZNOYHj6sLDEOfZVYvwMDQ/q6YXrSfTt7BZS0TOt3hyjuXEae5NpSGkQksGCeJQSx77AoW1E6JCaO7S5YFlZZnF/PD9NJ5KHiv6pmGcIqpmbzMK+slaZJLKy7kp4EfrY5stLnCZzb6gI9jWIyM7mlB8xLwPnzkjIENRHDJFhYOVQoNF9rwPCNnDJncGn/6LKpCbW2yKbF/WvOwmGookEXKhN8d7R91W6jQykH5aR7HuUdCQwxMYDdHLqMk0swFwVw+ySZJwt+hdkpMo6pIIKEggqejGBmrufhM5RHKMvACa+W30XNEO1Y5G8TtgG8zYLaRUxWpZlYvt0Omva7ixLx37L0So7hZr6c6GK091tsrIDnCNy5kdEHdqwlAVF6ByeYmCb2gRRhrnwFYc6FBvpHIBHyTqAiU7WmZ/f10c2x5qJTNkkDyuknP5OVA33L8J0HDD9E+4wBsabFS4AblyU7awgb7k7sEtk2dRsfkaa+3+UwEFdxMrmEoEM5sttCAbChQ/Tn/Q== X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: yLsgNAqzdXASEKKPkRuebwa7VJdv/eBj4pY9OrGSgUgWhmR1atM6Y2sLBnbCHBzXeGqRbS2ae6ricX4qJY86jotTFo0F+RS1gDd7NgimGFOwlr/EYAeO+aZ48jf0DXR+v+uoMpzIbKkXSeE7UgglOqm6kqRtnGSGfNVFpbo4DC8wgIhjbhrBsO6zhjQa53iz8QNf4HQkYAj6AykLxvjE3sC9avCZIs9KPDmpsDn+27mMA1nbEF3E2HO7W1T2kzvSsh9Ol98Pxq6Ev5bxZfV+xvLzaWK2WhhX+Nl1UAhArHOYmtXQ5BjkSRsnnPBRfXQ/0Ur2d2lTqQPQhpAnee8SymOIru35F5rNgbcRrPiKLn3ks6vkPiFEX+mvJ5MRQjcPm3iWnakORtM/cGILo7c/DeK60AZNrItfz46APETUvs988gxQs79OFA1HcM5OmlaoqP7ZTV4RH+lX90VTwbD4YH6BpRfyUjeE25l1g8TRftDDyMQJuijA5PNNEYYZApLBbnMIpmlWPsW1w6SWegtF6X0LUdm4xZ+YxEgHhcykuItjpV7JI7D1O/jdQtj9N56a9A4Yj/IKIBxeh6pIXlYj67h4gRWwiVdtQKD2hSza/rWbVuhfPn6tlBX0OI2o4/OLNAUG6G8jAG2OaKPWy9vTTGDxdHPETvVeak28xDo2o2PfpRfN0OfjpB/UjuKjbG1QxEhnLNYKR8X8ydTWtYRXIQ== X-OriginatorOrg: sct-15-20-3174-20-msonline-outlook-db8b5.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 8286e0d7-6648-4732-ac35-08d9a1be521b X-MS-Exchange-CrossTenant-AuthSource: MWHPR1201MB0110.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Nov 2021 07:15:04.5778 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1201MB0112 Subject: Re: [musl] [PATCH] arm64/sigcontext: Synchronize the type of the __reserved field with the linux kernel. On Thu, Aug 19, 2021 at 11:46 PM Szabolcs Nagy wrote: > > * Rich Felker [2021-08-19 09:38:41 -0400]: > > On Thu, Aug 19, 2021 at 07:54:12AM +0200, Florian Weimer wrote: > > > * Rich Felker: > > > > > > > On Thu, Aug 19, 2021 at 12:52:23AM +0200, Olivier Galibert wrote: > > > >> clang's compiler-rt sanitizer_linux.cpp expects the __reserved field > > > >> to be convertible to u8 *. So let's. > > > >> --- > > > >> arch/aarch64/bits/signal.h | 2 +- > > > >> 1 file changed, 1 insertion(+), 1 deletion(-) > > > >> > > > >> diff --git a/arch/aarch64/bits/signal.h b/arch/aarch64/bits/signal.h > > > >> index 5098c734..a46997e3 100644 > > > >> --- a/arch/aarch64/bits/signal.h > > > >> +++ b/arch/aarch64/bits/signal.h > > > >> @@ -19,7 +19,7 @@ typedef struct sigcontext { > > > >> unsigned long fault_address; > > > >> unsigned long regs[31]; > > > >> unsigned long sp, pc, pstate; > > > >> - long double __reserved[256]; > > > >> + unsigned char __reserved[4096] __attribute__((__aligned__(16))); > > > >> } mcontext_t; > > > >> > > > >> #define FPSIMD_MAGIC 0x46508001 > > > > > > > > The member name __reserved is not API, much less its particular type. > > > > > > The name is called __reserved, but it is actually part of the API. > > > We learned this when we tried to rename it: > > > > > > > > > > > > The name and its __ prefix are rather unfortunate, but we are stuck with > > > it. > > > > I question the reasoning there. Just because there are users of it > > doesn't mean it's API, *especially* if the users are things like > > sanitizer lib that regularly poke at internals that are not interface > > contracts. Use of a name like __reserved as API is *really* bad since > > it could even be something like a macro for an attribute in the > > implementation, rather than something available as a member name. > > > > My interpretation was that it's something like the powerpc reserved > > space where there's a separate pointer into it, which you're supposed > > to access it by. But that doesn't seem to be the case here, so I'm not > > sure what the right way to access it is. Do you have a list of > > software that's actually poking at it so we can evaluate the situation > > better for figuring out what to do? > > __reserved holds sigcontext extensions so i'd expect > code accessing the extended register state from a > signal handler would use it (includes fp/simd regs). > > e.g. chromium tests seem to use it: > > https://source.chromium.org/search?q=uc_mcontext.__reserved > > but the ucontext access code in breakpad is written > in asm so the c struct is not used in actual code. > > qemu seems to define its own types. and i don't > immediately know of other tools that poke at > sigcontext. I added a reinterpret_cast in https://github.com/llvm/llvm-project/commit/70986ea3d6aeacb5d10bfe3b75757611d4e7a379 (I have sufficient compiler-rt commits so they may not blame me) compiler-rt from llvm-project 14.0.0 will work with the long double version.