From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id So1dDfw9g2rPRi0AWB0awg (envelope-from ) for ; Mon, 17 Aug 2026 12:59:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1786985980; bh=Io988Cr4VN3G+O9VCizmFdwIuypXdBbCITU49CJex3Q=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=eirk7vwx4Lzcx/SuW6VA2CNk/y7ucIHvhdNYIDWibmm0mBrPYhva78FoNXlS5MPq0 OiBgZzbSwezQXcKLU5ymajREkZIZ56SUEhwJlM7O6kOPcWG5G2qCYGh0Zv+GfxRDxL XLeZpM3wvh2U+QrRZ/EzKNic9oOsNXWENvgmfiH8= Received: by simark.ca (Postfix, from userid 112) id 227F41E09B; Mon, 17 Aug 2026 12:59:40 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=lvOEN4rj; dkim-atps=neutral Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 964901E09B for ; Mon, 17 Aug 2026 12:59:39 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 264534BAE7F8 for ; Mon, 17 Aug 2026 16:59:39 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 264534BAE7F8 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=lvOEN4rj Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 1FF5A4BA543C for ; Mon, 17 Aug 2026 16:59:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1FF5A4BA543C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 1FF5A4BA543C Authentication-Results: sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1786985951; cv=none; b=lnC7MJAFbw3WVoiRgiLcM73KeCa4pQKNwZh0TX03EBye/EFCnGqJTj5CuhoL9qexePDfJhPn9ocEA+qBWvj+Zvg0tCOcAy8IWLJl/neWNg/eep/fHW8iCQIihKEZAu6AAYvh+R+mbMVLq8dY5lVFeT5nM2xME+Dtlp8kqKinEi4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1786985951; c=relaxed/simple; bh=Io988Cr4VN3G+O9VCizmFdwIuypXdBbCITU49CJex3Q=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=ShqrUR2Fz8bDerpHpcq2qWbwguZJeckd64Vjl6uKM5F1Bbpavj5fI2YVBCL3S++2yhHKM3aadO8qjEV7DwoBEdSoEdlyM4xVeVzkeOMyj+BoxS2ryZ49IENX7a+oEBu/yYMDoNr1tP3fCCtlP2uquswUtsg/wO9dOat9DGCcY9g= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=lvOEN4rj DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1FF5A4BA543C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1786985949; bh=Io988Cr4VN3G+O9VCizmFdwIuypXdBbCITU49CJex3Q=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=lvOEN4rj7TUJDMGSSVvhgvkBrS+Di+5GBR8ObsnU1ubPrQRP4IN7goGm0yKHoKkT0 bBXTOtrPUS+vxWmNGX4nOlKbWlEbFUStjdl1XQYmXLl4qkZL0SoQbQb+szlYGYLqLR g4nnDBdf2W0QIyRExQKTwuaKGIR/hoqsAGFIeCu8= Received: by simark.ca (Postfix) id 820231E09B; Mon, 17 Aug 2026 12:59:09 -0400 (EDT) Message-ID: Date: Mon, 17 Aug 2026 12:59:09 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5] gdb: align siginfo_t with the Linux kernel definition To: Matthieu Longo , gdb-patches@sourceware.org Cc: Luis Machado , Luis Machado , Thiago Jung Bauermann , Srinath Parvathaneni , "Maciej W . Rozycki" , Andreas Schwab References: <20260728123239.211813-1-matthieu.longo@arm.com> <50ac0d4d-7039-4ec0-837c-2b2bee7add3c@simark.ca> <10ce3491-6802-480d-b2c7-fc3bf0efb60c@arm.com> <64c7d358-b3b7-4f8b-8485-73c976203260@simark.ca> <1e524861-e8e5-42f5-ac40-66b017f15670@arm.com> Content-Language: fr From: Simon Marchi In-Reply-To: <1e524861-e8e5-42f5-ac40-66b017f15670@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 8/14/26 6:05 AM, Matthieu Longo wrote: > So, if I understood you well, you don't want to touch the current definition in > linux_get_siginfo_type(). Instead, you propose to define a new siginfo type as the data structure > below. Then, siginfo data should be cast to the new user-facing type before being returned. > Is this correct ? I think I was a bit confused about how the siginfo convenience variable is constructed. I thought we had code to set the value of individual fields, but that does not make sense. How it actually works is that we read the bytes from the target, and the type constructed by linux_get_siginfo_type (not only Linux, but all platforms) must overlay perfectly the actual byte layout from the target. But in any case, I don't think that anything from nat/ is used during that process normally. The type of $_siginfo comes from a struct type constructed with arch_composite_type & co calls, not from a literal struct in the GDB source code. > #define __ARCH_SI_CLOCK_T unsigned long > #define __ADDR_BND_PKEY_PAD (__alignof__(void *) < sizeof(short) ? \ > sizeof(short) : __alignof__(void *)) > > struct siginfo { > int si_signo; > int si_errno; > int si_code; > > /* Beginning of __sifields. */ > union { > > /* _kill, signals, _sigchld and _timer are tangled, so should be flattened > together. */ > struct { > union { > int si_pid; // _kill, _rt, _sigchld > int si_tid; // _timer > }; > union { > uint32_t si_uid; // _kill, _rt, _sigchld > int si_overrun; // _timer > }; > union { > struct { > int si_status; > __ARCH_SI_CLOCK_T si_utime; > __ARCH_SI_CLOCK_T si_stime; > }; // _sigchld > > struct { > union { > int si_int; > void *si_ptr; > } si_value; // _rt, _timer > int si_sys_private; // _timer > }; > }; > }; > > /* _sigfault, _sigpoll and _sigsys are not sharing anything, so are > flattened on their own. */ > > struct { > void *si_addr; > union { > int si_trapno; > short si_addr_lsb; > struct { > char _dummy_padding_1[__ADDR_BND_PKEY_PAD]; > void *si_lower; > void *si_upper; > }; /* _addr_bnd */ > struct { > char _dummy_padding_2[__ADDR_BND_PKEY_PAD]; > uint32_t si_pkey; > }; /* _addr_pkey */ > struct { > unsigned long si_perf_data; > uint32_t si_perf_type; > uint32_t si_perf_flags; > }; /* _perf */ > }; > }; /* _sigfault */ > > struct { > long si_band; > int si_fd; > }; /* _sigpoll */ > > struct { > void *si_call_addr; > int si_syscall; > unsigned int si_arch; > }; /* _sigsys */ > > }; /* End of __sifields. */ > }; This is a bit hard to read, but yeah I guess that having all the struct and union fields anonymouns would make the si_* fields accessible from the top-level, and that would be ideal from a UX point of view. So, we would like to model a structure like the above, but constructed with arch_composite_type & co calls. But we'd need the old names to keep working. You don't have to worry about this though (unless you want to), it's out of scope of your original patch. Simon