From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id olvEBfcgm2o4aCkAWB0awg (envelope-from ) for ; Fri, 04 Sep 2026 15:50:15 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=jBnESwiV; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id E8BEA1E166; Fri, 04 Sep 2026 15:50:14 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::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 36ACE1E033 for ; Fri, 04 Sep 2026 15:50:13 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 383164BB5893 for ; Fri, 4 Sep 2026 19:50:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 383164BB5893 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=jBnESwiV Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id 5B15E4BA23FB for ; Fri, 4 Sep 2026 19:49:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5B15E4BA23FB Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5B15E4BA23FB Authentication-Results: sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1788551386; cv=none; b=t6HCNU98LIGKHIqRXnDekt0PqgP5URzU0ixEDwu1mAw/91KQJfKHcOhLkA0Hy84stz4dySsoTK9OY1dkZLe98ftSOL8F1Yf3TQWgtuFhjjQehmAkOHeVggPOdOgj6Jp7gEodfJEQ+uf54Y0laZYPqX4TT8DWQnaJ2m61EQ8geQk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1788551386; c=relaxed/simple; bh=KFPzhuOHC/0uDFEipwRxT1BmaK87TPrSniJrGUb4bqw=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=Wl6PAONnVtdsm7y9mtwR7z5Id0WdJY3ZJHFxoNnmHdTpbHeDHkfjkYrNmCt3xtaSekb3aDKmWaaAiETVBU9hIeWy8DCUVcCm1H7M6Fnx+JCeOUde8kDJ0bNm1WoUobzqXlnFmVg/apYIHo0IA8MIrm5iACV7+1pYtHS3kZuFLeI= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=jBnESwiV DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5B15E4BA23FB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1788551386; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QKv9z0ip6MK+a1eCbmAWTIxbrOI2HSau2/zbziLstBI=; b=jBnESwiVt0kBpadzA++EM3yUPqnlRIm9fPlepyAnRcAh66N41Hm/OxDjYqgbxs8yxRrzsV qliVPcm9CYqFRUMKpMi92T4G/xlBFzWaNgcxL3KQ06ZPZJx5PwgcJNk0w2om3GrchiVmmJ PEctrReZUBv6WAV2NlpUJ42TonVV0+o= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-377-_8YgthEnNUa4BVZhMzUP9A-1; Fri, 04 Sep 2026 15:49:44 -0400 X-MC-Unique: _8YgthEnNUa4BVZhMzUP9A-1 X-Mimecast-MFC-AGG-ID: _8YgthEnNUa4BVZhMzUP9A_1788551384 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-47d81cf0c4cso972416f8f.2 for ; Fri, 04 Sep 2026 12:49:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788551383; x=1789156183; h=content-transfer-encoding:content-type:mime-version:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=4ZN0qQzNYaZpE59CJf4Ik+FGWN9jWvCmxxXlXc61aL0=; b=khZaWvlEeqCi3k4g0PNGVs3qd6IiT3K2u03a5nPTw3Ra2q586DcXM01JkeFelnihuR PMFp0ikngtD7am+ns4GT5btqgkjWdqfFIckfIsYCGFBJHGS56P3Ukx6b3oiTRHGLV8z7 cmDnxn5WTcRPlRbbhToDFL/w7AnnIveWSzuHsh4GRpKN6IH8tjM8/vqCIriSkZM/jUyX kqQofEDbiP+ylU9WFIyz/+QIfn+BTI9F154B4Tfxm3anU4wordW6xkMrhq/LayZ8PgQj xXaDbgVFcYMHpyNhd8iabDhXStozdrwCp72sQpwn8mWcuwr9EFirra4ZfEW0ojSWFzkX jyqw== X-Forwarded-Encrypted: i=1; AKwUvByV2CBt7hQ1MfGBR+73KqbL8bdoJnXWDx4KuvAHYGpcTF27XK6DhPcxdPv+jA3hNom/GENqw3tkG9swRw==@sourceware.org X-Gm-Message-State: AFuF++mQYV78JuCQp1dTkQNJHj7n9i+mlnr1PC0Xm5m3L1CaluqlE2so GGiza9YMA7kheu8S8EpSvaYalk7c5+NBPgs2Sb4e1Day68JgHGfwqvtg3HcBnjdS3RdD6kUnm6X H3bLTGjtqPTm+DcUd3a83oaruLlhKvIfzekKY8acSATb4KhLgBVXPd5+F0aqKIeU= X-Gm-Gg: AYBFou3YcdiQlTDrlQ5/NoyDinGIQ+I+uWKwhBirgs1OizjxocFHZBtusAkfEnQrOWm los3hfnKOzB5rTE9VD2sXkrT4itkJv3m3QGRqfPC37ZIHFKw5t5cESur6Xo9HwJKVgS5DggnX+k gcG24NdecTDmWf4nFwxN9DO7+YjPkbaZxe9y35EodSbuNhNjRlF1VppBdVuhxJxeEJTEJq4xSoX tI0hmnOzHp/g3LcmYxi4v1H9HkWYLbHvP6IlB57VmseyntcED2DL0N2BfwzmZC048MqbT+gfruP XnLy8JEcce696dTnSG0dNtwpxCxvJ8ySNuyR/IklPVPryWYMhGaVnky3cP4yoJI/rqg0cZPGVfB uLzLBeajLJ/WwO+fBdceZzoOlumk= X-Received: by 2002:a05:600c:860b:b0:49c:ee20:e787 with SMTP id 5b1f17b1804b1-49cf7fe62e9mr162386945e9.1.1788551383642; Fri, 04 Sep 2026 12:49:43 -0700 (PDT) X-Received: by 2002:a05:600c:860b:b0:49c:ee20:e787 with SMTP id 5b1f17b1804b1-49cf7fe62e9mr162386265e9.1.1788551383213; Fri, 04 Sep 2026 12:49:43 -0700 (PDT) Received: from localhost (128.223.159.143.dyn.plus.net. [143.159.223.128]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49cee5d476esm193973375e9.1.2026.09.04.12.49.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Sep 2026 12:49:42 -0700 (PDT) From: Andrew Burgess To: Matthieu Longo , gdb-patches@sourceware.org Cc: Luis Machado , Luis Machado , Thiago Jung Bauermann , Srinath Parvathaneni , "Maciej W . Rozycki" , Andreas Schwab , Matthieu Longo Subject: Re: [PATCH v5] gdb: align siginfo_t with the Linux kernel definition In-Reply-To: <8733vprn3e.fsf@redhat.com> References: <20260728123239.211813-1-matthieu.longo@arm.com> <8733vprn3e.fsf@redhat.com> Date: Fri, 04 Sep 2026 20:49:41 +0100 Message-ID: <87zexwre3u.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: UBC1yJm4LQQSqCRMuhDETM00GYk6xvwpYyUNEvozwKk_1788551384 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 Andrew Burgess writes: > Matthieu Longo writes: > >> GDB's current definition of siginfo_t is missing many fields present in >> the Linux kernel definition [1]. >> >> These fields are useful for providing detailed, user-friendly diagnostic= s >> when a fault occurs. Some new AArch64 extensions, such as Permission >> Overlay Enhancement used to implement Protection Keys [2], require the >> debugger to inspect 'si_pkey' alongside 'si_addr' to help the user ident= ify >> the problematic key. >> >> This patch aligns GDB's definition of the __sifields._sigfault member of >> siginfo_t with the definition from the Linux kernel master branch. >> >> To avoid hardcoding the field access paths throughout the codebase, this >> patch also introduces compile-time accessors for the siginfo_t attribute= s, >> centralizing their definitions in a single location and making future >> updates easier. >> >> Finally, extend the testsuite to verify access to the new si_pkey field >> and its preservation when modifying $_siginfo and when reading core file= s. >> The tests in siginfo-obj.exp rely on the siginfo_t definition provided b= y >> glibc's , which does not yet expose all of the fields present = in >> the kernel definition. As a result, the tests cannot exercise every newl= y >> added field and therefore focus on si_pkey, the field motivating this ch= ange. >> The test validates that GDB can read and modify the field correctly; it = does >> not attempt to generate a real protection-key fault. > > Hi Matthieu, > > Please see this message: > > https://sourceware.org/pipermail/bunsen/2026q3/001504.html > > This is an LLM generated analysis of this patch which makes the claim > that si_pkey is not accessible at the glibc level on every > architecture. > > I tried on a couple of compiler farm boxes, but ran into some TCL > version issues so wasn't able to actually make-check, but on a ppc box, > if I try to compile gdb.base/siginfo-obj.c manually I get: > > $ gcc -o siginfo-obj siginfo-obj.c > siginfo-obj.c: In function =E2=80=98handler=E2=80=99: > siginfo-obj.c:38:31: error: =E2=80=98siginfo_t=E2=80=99 has no member n= amed =E2=80=98si_pkey=E2=80=99 > unsigned int ssi_pkey =3D info->si_pkey; > ^ > > This test file did compile before commit 9c99987237dcaca0c6c493d6a. > > It would be great if you could take a look at this. Should the si_pkey > parts of the test be optional maybe? Found some time to look at this again. I suspect the compile farm machine I tried is just old. I tried a more up to date machine, and this all compiled fine. I suspect we're OK with this test just not working on older machines. Sorry for the noise. Thanks, Andrew