From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id aTZ3F6YbNGoOwQ0AWB0awg (envelope-from ) for ; Thu, 18 Jun 2026 12:24:06 -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=eTC7AsCy; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 487091E098; Thu, 18 Jun 2026 12:24:06 -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 23FBF1E070 for ; Thu, 18 Jun 2026 12:24:05 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B59D54B9DB48 for ; Thu, 18 Jun 2026 16:24:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B59D54B9DB48 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=eTC7AsCy Received: from mail-yw1-x1133.google.com (mail-yw1-x1133.google.com [IPv6:2607:f8b0:4864:20::1133]) by sourceware.org (Postfix) with ESMTPS id 7405B4BA2E29 for ; Thu, 18 Jun 2026 16:23:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7405B4BA2E29 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 7405B4BA2E29 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::1133 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1781799808; cv=none; b=V1Wz9lAAC+Kwtd+LyEUeXjTDhclTVdkDLOCy1p0zZKWV45RZTfqFGwMboWN7UhKCNL6nxizI6fOB4rhO8mH9KuIZ78ifEsDu7D4p2OCPstr02pvyg9w2SCe13K6tytMlBGRc3MxgKq2YOHPBpf78jqNYyCcgNI3F5eCqZkHgBqo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1781799808; c=relaxed/simple; bh=+LLmgXmu9z/o6AtK0jwZd0wpkgIvLyer3cMNz8u8VQU=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=hwMNUOL+fjiauquqfuv/0TIpWSEp4kzdm95E/x6DipFSYdZGZgALGOvLmpfPXiv1qM2uRE0DvueTmJvIEy4AWUYlUKB5cC5CbRuU+Eyq9Si+ByMv6UOoURQZWs3rRphuoMxkfa2jA4Xfm4jMguB1ygrWxWS40ivKs6KvNno2+Fk= 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=eTC7AsCy DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7405B4BA2E29 Received: by mail-yw1-x1133.google.com with SMTP id 00721157ae682-7f69b71f7b2so14943317b3.1 for ; Thu, 18 Jun 2026 09:23:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1781799808; x=1782404608; 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=E3ku6ZRLwPOjyK0+y7LEnHNZhhqXhZbi8rXTjZVKgMI=; b=eTC7AsCyV21CKwhtlnCS0bBfHCChnf1B/jiH+SOyZPjc2mkG8gys6NhlqULEmrm7eE vu1y0KJHUbF2FMIMe5Kyufq6qINWOHmY8Se7A4wCG/ocOLxElc83OrfjMQJeLHKxGnSU DUsgIZSdjqoxO7MykKDsdPi+7wFjdlJD7VODDDMcl2x5U8+PLI/DxDIaKkbvsaDFjwvZ sf07XxlxN04/aV6sfyHuTRX1a7GVFmP6DyCCxSuU7gFG4/osj6LlJvITJAxJtJtuAVra mnc3z/DnN8H7hAspe7mjt7FPKK5vK3SqL0HALxTQWETCw3TCLu434SrulI+BuKJuAN0e lyig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781799808; x=1782404608; 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=E3ku6ZRLwPOjyK0+y7LEnHNZhhqXhZbi8rXTjZVKgMI=; b=SIAAc0CCBMBCHGE+DasVYLPd33CE1A3QP+I33tfEvvqu6u+voPLFq0D7rpdNXx7msE LfHv3ELyYp8J7bA1uaNAs0klzd9xPRdYiXPOzV3E4mfGUfSljPUjY5ytqCh1/57RSP2l wQ8x1XsFtQzDebVZ4JgKZv53by/4VbcqFFY7Wi5YF9IDuDnuduQymK05/A/2hb0lH7V7 A2Hnn/p7xjF6gJJAUZzWbCxIHKNiyXsC8HLeXPyzrFvFlyQkEykmAlSJhTcqnHgkSfn6 bqmCtFBg/3uH0a2+qWLCxY3x3t6upqTWf1TjrC0XR9QFBFJIPZQin30KymAQV16Bv8jn YFNQ== X-Gm-Message-State: AOJu0YxcnlNBT60kIpKzaM+E/sRz9xaXg/6Xf+FNcap7bk8s8d/VAiR5 ALlJ+GMDg/BOhPG9B3k2LE+id7hNlcaN9NmK4jtEtfK2051JyRWj1XUljNvHwvlup98= X-Gm-Gg: AfdE7cmNnV9WpPDBnyam8+O+iltp3FSZXmuhMcRPCHXbyImroE1fEB9voIZQWnCyueq ywqJBNnl7eEswkWG+EbUmRGGmGw9w5MnDyYNN6EEdR8ihI7+Ril16qDhUCxrg9mnHNCevBHN859 Sv12lQ3KokQ9UiMc5CzdhOiGbLUhBKI50OmVounVdUR/yETTW+hrYG/m2tVFqLhknfaGMReZNDa VAxBaomMDQWF3Wrgj16sV6TJDQY3V6/X1kR9pT7TxyKqluHc4+PWMHfKZWI2wDiYaIDVhOBoWE8 8fsEmSxEdY9tsxGDokAHKHWSm8t//MLjl6Fo9SXxWpEuLk0LCbQrD1oY7Io6xvNoKfx75iCx/Ft sMuP6tqXuDzpe8kzVCOwnTn3beVqSm8g98Z33L4Z0oCL8G+qn5224P9Jgi63ZZUZbk9mNZalI5/ K0F0DBNRPFjznGrHbh1XFortk= X-Received: by 2002:a05:690c:9993:b0:7dd:7b0a:8197 with SMTP id 00721157ae682-7fe5d89dc58mr104964247b3.4.1781799807657; Thu, 18 Jun 2026 09:23:27 -0700 (PDT) Received: from localhost ([2804:14d:7e39:8083:33bc:f32e:9aa5:b915]) by smtp.gmail.com with ESMTPSA id 00721157ae682-7ff53aa2be4sm32246267b3.42.2026.06.18.09.23.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Jun 2026 09:23:27 -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: <5e489d6c-199d-4e0d-921a-0ed0164a6f1e@arm.com> (Matthieu Longo's message of "Thu, 18 Jun 2026 15:02:22 +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> <878q8c7dqu.fsf@linaro.org> <5e489d6c-199d-4e0d-921a-0ed0164a6f1e@arm.com> User-Agent: mu4e 1.14.2; emacs 30.2 Date: Thu, 18 Jun 2026 16:23:24 +0000 Message-ID: <87wlvv6cn7.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 18/06/2026 04:02, Thiago Jung Bauermann wrote: >> Matthieu Longo writes: >>=20 >>> On 17/06/2026 07:07, Thiago Jung Bauermann wrote: >>>> 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 siginf= o_t =E2=80=94 >>>> which GDB's compat_siginfo_t aims to represent. >>> >>> I imagined that compat_siginfo_t was also used in the case when the inf= erior is an >>> AArch64 >>> process, while GDB is AArch32. >>> Hence ... >>=20 >> 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. :) >>=20 >>>>> However, I am confused by the definition of compat_siginfo_t in gdb/n= at/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= the 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? >>> >>> my surprise when I say the definition of _sigfault._addr as a uint32_t.= This would not >>> have worked in my understanding. >> >> Yes, indeed in that case it wouldn't work. > > If the feature that requires new fields in siginfo_t, is only available A= Arch64 only, > there should not be any reason to change aarch64_siginfo_from_compat_sigi= nfo and > aarch64_compat_siginfo_from_siginfo. Is this correct ? Yes, that is correct. compact_siginfo_t only needs to reflect the siginfo_t that the Linux kernel passes to AArch32 processes. > If so, then the current patch is complete and ready to be reviewed. Ok, I will start reviewing it today. --=20 Thiago (he/him)