From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 76baAMxfM2oAwAwAWB0awg (envelope-from ) for ; Wed, 17 Jun 2026 23:02:36 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256 header.s=google header.b=NjNvQC+2; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id EAF721E098; Wed, 17 Jun 2026 23:02:35 -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 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 CEF0F1E070 for ; Wed, 17 Jun 2026 23:02:33 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 764A04BA2E36 for ; Thu, 18 Jun 2026 03:02:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 764A04BA2E36 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256 header.s=google header.b=NjNvQC+2 Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) by sourceware.org (Postfix) with ESMTPS id A7D634BA2E16 for ; Thu, 18 Jun 2026 03:02:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A7D634BA2E16 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org A7D634BA2E16 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::e33 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1781751725; cv=none; b=iceZ3T+9+VFupc9Ys+qc9OShuiD7wF8RxJiB0b3Oa2x2PpOHwnK8G/VMLtsgchGOza+opo4IK8kpeklCRsyVmXAX57GKmIX2wl6e88fNuOxhrckaX1ubBT6x/Efpu2vMcyhHlmzhKwvcun2PuAujJ16N0eSEXRdNPpDt64GN6PM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1781751725; c=relaxed/simple; bh=g1O1dQFcmPQczN2wSoGiGZCnHvGPMqLhVXrjsUq3Npw=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=i3K203G3CeZUFXjc/9igSBlGP+v1cQ9/TgIAW6JnH9sqoRqplzXJPUKCXKiKgxYB9nszChHjG142OmbB+5UY5T7uvAOEhJa4R+8RzW7Pn2NHemCTtKjsOXgEj+PW0yVkeExi90bmNXCYGXau5WRMYaRwkJFCdop06wFyIhyebek= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256 header.s=google header.b=NjNvQC+2 DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A7D634BA2E16 Received: by mail-vs1-xe33.google.com with SMTP id ada2fe7eead31-6c25b040555so392086137.1 for ; Wed, 17 Jun 2026 20:02:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1781751725; x=1782356525; darn=sourceware.org; h=content-transfer-encoding:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=tyV5jhLoe7JFiTUq+q+o5ydbWfpxxlw6lBvYWvx0RwE=; b=NjNvQC+2TZcIgZTqMq2NL8plLPUhDTh12sn58CKsxwNTCAiZu2m9KRZSqNTNDnl5FI gEO7UKTLhFdAEODEpECB8YyqDvNywlIVbheLkKnLykR2giOHlWK5OPSvgyJAIzA765Eg z5Sg9jiXOpg2qpYvMXXxIMFzKwfqbTFSwino9/iYrPfd7XkfGONcsLlMIbESa58+X409 Eb1nyjAvJwJ5QLigdlm/KKT7RSBe0TJIyuwdvobhrKRZqQxDv/kT3spPdqkDG2t2pBpL 1bMUlZAaGql+KLAUjHu/hvxq2uMBLNlMUWxZEtX/8JyKZAfAt6Eq4jsjLNCuaR06OMwl xCdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781751725; x=1782356525; h=content-transfer-encoding:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=tyV5jhLoe7JFiTUq+q+o5ydbWfpxxlw6lBvYWvx0RwE=; b=IehKFlyJIUpcPmbSkqV6IyVXvgiH0iu+QfXcuK7g93LcvGWC+oRdVpel0yF/EHcP61 fMrNXZrMkxVOxwp+5ZqgzXYwRIkXj2BsjZPoTSdj7FdUt14/Di4iDp6YN+ETd3iQk+eu nqLK44YrbBjKNu2x0NJOlyIcrO30ApJguxAQPCqYfwZ58wVspbTOjFxlT57NdOdtsDdd 400MGde0TGBpTtlCPY0SBrIl6f5ja4P2D5OyR0Uo3Gmc2ySt8MWHWy1NJxGISWnHzfdI BLD2Q+77CaTPFZr/pdMMIegmhhjXEBpC0v7uJ3JDOJNvjhjUJ/+wSTAxwoSpL2DIR0Jn JTMg== X-Gm-Message-State: AOJu0YypQC7slrAoN/QiKwPcsfHQXyoihNNHXZZ+laKl5VggBiymWSn4 Co9HxMlkNzTUg2WQ6yV7uAuT8wU3U9/6UWK1I1ZKTyQp5I2b7vHknhqNSCP2BnORdEU= X-Gm-Gg: AfdE7cn8fUbGi5ikbDIoLZ85iClXRQz+FCfOYU/tpTI6LttOTB1wtw5/19hqKNmoFm+ VkzNCqVZskIzFHHSYoIaxeFHtUFdsgzD/UUt5I3ByL5B/TypDU3GXL6zRNkt1rz920AuRFW43vK o4eO+F/mJsUQCzBVgOfbVrm0/U0m49USzp9nIPFC1aR/I1ptSv4HxtHAm+V7c0+1xTpKf4HPebd zLPrzkTlwl/v8JTX9QkLhxQYv3TvCVaDtZzimys/4gh32FGib6JM1q35exAXNB+2YCWjHNQwzYe swe4Cyd5R7aQotoZ2SwOs8EMzQ48ZmePYZyFMYQubaB60KaHVwYiiQDGXeS/S3+KO7AZtf0VhMg qZHRwhd9iw5/9k7DwsDw5RWI0SHRdim0F2SuUDuFi3zfBH/ReasDwxMsdLZZkIh1P05z/2QJWJp /KDNjdTnYTDXaHVmv1ARQXi+k= X-Received: by 2002:a05:6102:4421:b0:62f:5908:648a with SMTP id ada2fe7eead31-7246da56addmr3829178137.28.1781751724633; Wed, 17 Jun 2026 20:02:04 -0700 (PDT) Received: from localhost ([2804:14d:7e39:8083:f04c:42e3:5943:38f6]) by smtp.gmail.com with ESMTPSA id a1e0cc1a2514c-966a609ec7bsm8377791241.2.2026.06.17.20.02.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Jun 2026 20:02:03 -0700 (PDT) From: Thiago Jung Bauermann To: Matthieu Longo Cc: gdb-patches@sourceware.org, Tom Tromey , Andrew Burgess Subject: Re: [PATCH v1] gdb: align siginfo_t with the Linux kernel definition In-Reply-To: <300c2d55-c729-4f65-8f35-f0c15500578b@arm.com> (Matthieu Longo's message of "Wed, 17 Jun 2026 10:11:35 +0100") References: <20260612101610.592338-1-matthieu.longo@arm.com> <63fce133-4d28-4629-9a60-6d14cba49b86@arm.com> <87se6lhf87.fsf@linaro.org> <300c2d55-c729-4f65-8f35-f0c15500578b@arm.com> User-Agent: mu4e 1.14.2; emacs 30.2 Date: Thu, 18 Jun 2026 03:02:01 +0000 Message-ID: <878q8c7dqu.fsf@linaro.org> MIME-Version: 1.0 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 Matthieu Longo writes: > On 17/06/2026 07:07, Thiago Jung Bauermann wrote: >> Hello Matthieu, >> Matthieu Longo writes: >>=20 >>> On 12/06/2026 11:16, Matthieu Longo wrote: >>>> 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 diagnost= ics >>>> 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 ide= ntify >>>> 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. >>>> [1]: https://github.com/torvalds/linux/blob/2b414a95b8f7307d42173ba9e5= 80d6 >>>> d3e2bcbfce/include/uapi/asm-generic/siginfo.h#L69-L100 >>>> [2]: https://lore.kernel.org/all/20160212210213.ABC488FA@viggo.jf.inte= l.com/ >>>> --- >>>> gdb/linux-tdep.c | 39 +++++++++++++++++++++++++++++++++++++-- >>>> 1 file changed, 37 insertions(+), 2 deletions(-) >>>> >>> I was not sure who I should include for the review. Please feel free to= CC the right >>> persons if they are not already in the list. >>> >>> I tested the patch above, and it seems to work fine without any change = in ./gdb/nat >>> However, in my understanding, compat_siginfo_t should also be impacted.= Why is it still >>> working then without any change ? >> =E2=8B=AE >>=20 >>> aarch64_siginfo_from_compat_siginfo (in gdb/nat/aarch64-linux.c) and it= s friends for each >>> backend seem to provide some conversion logic between the siginfo_t fro= m the system >>> (/usr/include/asm-generic/siginfo.h) and some internal representation c= ompat_siginfo_t. >>> From my research, this seems needed because, if the host and target sy= stems are not >>> using >>> the same ABI (endianness, size of a pointer or int, etc...), GDB cannot= rely on the local >>> definition of siginfo_t to interpret correctly the data in the blob tha= t it received from >>> the target. >> compat_siginfo_t is used when the inferior is an AArch32 process while >> GDB is AArch64. This will cause the 64-bit kernel to use the syscall >> compatibility layer =E2=80=94 and thus the 32-bit definition of siginfo_= t =E2=80=94 >> which GDB's compat_siginfo_t aims to represent. >>=20 > > I imagined that compat_siginfo_t was also used in the case when the infer= ior is an AArch64 > process, while GDB is AArch32. > Hence ... Ah, ok. This isn't supported, at least in the Arm port. I think GDB in general doesn't support 32-bit GDB debugging 64-bit inferior, but I could be wrong. It's certainly not well tested though. :) >>> However, I am confused by the definition of compat_siginfo_t in gdb/nat= /aarch64-linux.h >>> for instance. I see that addresses like _sigfaul._addr are converted to= 'unsigned int' >>> (that should be equivalent to uint32_t I guess). Why is this working ? >>> >>> Please, could you provide explanations on the above, and guidances on t= he changes >>> required >>> in struct compat_siginfo_t ? >> I'm not sure I understand why it wouldn't work. In the example of >> _sigfault._addr, it is an unsigned int (equivalent to uint32_t as you >> point out) so it will match the width of the void * used for the >> corresponding void * field in 32-bit userspace. This is converted to >> siginfo_t's 64-bit void * in aarch64_siginfo_from_compat_siginfo with: >> to->si_addr =3D (void *) (intptr_t) from->cpt_si_addr; >> Do you see a problem in this process? >>=20 > > my surprise when I say the definition of _sigfault._addr as a uint32_t. T= his would not > have worked in my understanding. Yes, indeed in that case it wouldn't work. --=20 Thiago (he/him)