From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id zpQqHyT6sWqFgDAAWB0awg (envelope-from ) for ; Mon, 21 Sep 2026 23:46:44 -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=AqJOoEnE; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 53C9A1E051; Mon, 21 Sep 2026 23:46:44 -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 595F91E033 for ; Mon, 21 Sep 2026 23:46:42 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3259F4BAE7CC for ; Tue, 22 Sep 2026 03:46:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3259F4BAE7CC 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=AqJOoEnE Received: from mail-ua2-x10.google.com (mail-ua2-x10.google.com [IPv6:2a00:1450:4864:39::10]) by sourceware.org (Postfix) with ESMTPS id B5AA74BA902F for ; Tue, 22 Sep 2026 03:46:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B5AA74BA902F 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 B5AA74BA902F Authentication-Results: sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:39::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1790048777; cv=none; b=Bp1oRZ0JsNodtqqbkTpJ9kRakqmqFXV15WjDV0AgMgtIj5ZfojyiQluyGkds8rUmmcl3ABouRy/JUIl/SRw23oi0vlALXtxP14SaM4oBncbYC6xtjdg/GT1fP43/GeshGuNQcj6Y6pVdAZruD8gVfAmr1LMIfPTFecPBz5Oa35Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1790048777; c=relaxed/simple; bh=ZsY7fb+i/e0xA9Pmdqu+ux7adf/UZ5WsSNRbM+GfBwk=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=Z+Bz3xx1haSLhm1DUkAQ7+i1ZBEewubOh5AOMwAX3bRikmo0Zclmdi9ul2HoOAzLFQsjajBNCMg2NgeY71q0/7UnSzFUdJpHN/5WMswgMZjIQgBMLjFMaT5tiojGz+hXx0oHyKD11guImr17eCSlCEkK2+VDXz0FjSol29W84l4= 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=AqJOoEnE DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B5AA74BA902F Received: by mail-ua2-x10.google.com with SMTP id a1e0cc1a2514c-97e9d8a796aso823301241.0 for ; Mon, 21 Sep 2026 20:46:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1790048777; x=1790653577; darn=sourceware.org; h=content-transfer-encoding:content-type:mime-version:message-id:date :user-agent:references:in-reply-to:subject:cc:to:from:from:to:cc :subject:date:message-id:reply-to:content-type; bh=df9sFf2HAolHhIgwPYCAKkWSJ7wf0as6ftEbPPgEQWA=; b=AqJOoEnEeSMoi2zNfLto2peHSxD/+5S8SSXKZ+dCEkCuVpBaQxLtFhQwwze4E2o063 oZia9iuexNX52PCcLsJ25xhjAT+jqoDJTALMGdzT3S6t8qex/F0DRKTVKT+e/gKAnoCR tQkkgUOVrHLnjptvwR5XoOXNIEy2VXG5rWEj6FMHhetR+uIGIb6gJyYbbtwbciUpH15Q bTEO2NVJIvY5PZU8CDKfzsfnNsP7nMgoejMBi3bWIxCMlxCKL8OlcsYNtMW511ty7omk E5FrPtwRbWIN3E7eF6WU6AuyMnREY7/cOkjlpktsQbpMQBWeyQkmebgZvOZDkr2zaTiK pcOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790048777; x=1790653577; h=content-transfer-encoding:content-type: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 :content-type; bh=df9sFf2HAolHhIgwPYCAKkWSJ7wf0as6ftEbPPgEQWA=; b=cbUzyz5c3YfEl2/Vp3AjyZz4HmwotOYb26wS4G5kxfKjx8nGyRiqyjgzb2BwSraK5Y tHx2ECbdOJH3rcLnjtiJrpwkMv0Ml4RRhmHlCuDMFoedgzq23HSC4t2lZ2hi9gFQ99uB U1LkoTh0K+Eq8AWYE4KCu67CGJhnzesDV1akukmewP0ScWweDszSjcR+xmGFvx02u0Sj sG+A08xg9dlBQRuML1kEAyU1pTsAZHFJCE8J/vxxNTOHrOxL4+V0yl7WUzz+MaiGi0GL /mQGvelcwoH4Vv4N+cPSjKkk4mFCl6gNFls9WkpX56ZnFWXAzTxj9vGX1X0cR7ur511R YZow== X-Gm-Message-State: AFuF++lffcK5Xye8Zfoa9T8lXVAI5xaGWHJMfcL1q7ZvvV7xhuFjgJz8 n9nXJJTbNLMfEJirjGletln5YwvHNi3+8CkoW3jkvqFfZlJdPsZXL3NuBmLfWQxSteY= X-Gm-Gg: AYBFou1DLtXLxoZpJeb+ci7LTtP9RvhXMU5dDi8W6+dQnP+xPk7rwrLQWvGSGtkC4We yxsdghr23VIwMJG77a6RKdLJH3ZpVIh/9o7FJVC1gtXKNSMFa0SlOn1Z2wItSmYwtPR61/tFX6l fMe6KO+SX+oXwlD9zb6WxZVblwjW7TXNQhrFfs4KxXqNE9IFBipJsYsVlsEcUQw8/U7lj2Hwspx RFR7XVP9ZyqI3dWkObrlIlChNl9n0k7d8FGDEkR2A0b2nYR5qpi4c2bTyxAv15eNaMNkz2Equqv mn6BWMcuV4keoTvg2kDvp/dvPMrbSWNWshy111Ko5j7etWptydnr9b+mj5k9pesZjPj1nIYyUgN ovuWgE6vn3xvN27qDyte2OsPEbIR9jLYNzRAOCM4cFY3QlxqIC7d2UV94UhN+ZfSHi7Cy16yyNI fJ61tbKl8Kc33k8WSPugrXNpjCPfp/IHMFg7PdeTee7n8k3uJHarL0AHpwpnia/i+CKlXWpIaRH STaMBUhFEmuJQPu/io= X-Received: by 2002:a05:6102:6c4:b0:7a5:71a3:55b3 with SMTP id ada2fe7eead31-7aa9fbbb254mr1588215137.8.1790048776819; Mon, 21 Sep 2026 20:46:16 -0700 (PDT) Received: from localhost ([2804:14d:7e39:8083:f04c:42e3:5943:38f6]) by smtp.gmail.com with ESMTPSA id ada2fe7eead31-7ab17f37bdcsm493901137.6.2026.09.21.20.46.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Sep 2026 20:46:15 -0700 (PDT) From: Thiago Jung Bauermann To: "Joos, Christina" Cc: "gdb-patches@sourceware.org" , "tom@tromey.com" Subject: Re: [PATCH v4 10/13] gdb: Implement the hook 'is_no_return_shadow_stack_address' for amd64 linux. In-Reply-To: References: <20260708143639.2214689-1-christina.schimpe@intel.com> <20260708143639.2214689-11-christina.schimpe@intel.com> <87v78mrcz2.fsf@linaro.org> User-Agent: mu4e 1.14.3; emacs 31.1 Date: Tue, 22 Sep 2026 03:46:13 +0000 Message-ID: <878q4u54oq.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 Hello Christina, "Joos, Christina" writes: >> -----Original Message----- >> From: Thiago Jung Bauermann >> Sent: Donnerstag, 3. September 2026 09:50 >> To: Joos, Christina >> Cc: gdb-patches@sourceware.org; tom@tromey.com >> Subject: Re: [PATCH v4 10/13] gdb: Implement the hook >> 'is_no_return_shadow_stack_address' for amd64 linux. >>=20 >> Christina Schimpe writes: >>=20 >> > diff --git a/gdb/amd64-linux-tdep.c b/gdb/amd64-linux-tdep.c index >> > 42a62eaa975..d98415b8989 100644 >> > --- a/gdb/amd64-linux-tdep.c >> > +++ b/gdb/amd64-linux-tdep.c >> > @@ -1960,6 +1960,62 @@ amd64_linux_top_addr_empty_shadow_stack >> > return addr =3D=3D range.second; >> > } >> > >> > +/* Return a shadow stack frame info, if the shadow stack pointer SSP >> > + belongs to a valid shadow stack frame while the element on the sha= dow >> > + stack VALUE does not refer to a return address. This can happen, = for >> > + instance, in case of signals. The old shadow stack pointer is pus= hed >> > + in a special format with bit 63 set. In case this is true, a valid >> > + shadow stack frame info is returned with its attributes frame_type= and >> > + non_return_description configured to ssp_frame_type::non_return_fr= ame >> > + and "", respectively. */ >> > + >> > +static std::optional >> > +amd64_linux_is_no_return_shadow_stack_address >> > + (gdbarch *gdbarch, const CORE_ADDR ssp, const CORE_ADDR value, >> > + const unsigned long level) >> > +{ >> > + /* SSP must belong to the shadow stack memory range. */ >> > + std::pair range; >> > + gdb_assert (gdbarch_address_in_shadow_stack_memory_range (gdbarch, >> > + ssp, >> > + &range)); >>=20 >> I made this comment at another assert in a previous version of this seri= es, but >> it's valid here too: > > Hm, I don't remember it... :/ Did I fix it already ? Or can you point me = to your comment? It was during review of v2: https://inbox.sourceware.org/gdb-patches/87bjh1y3xk.fsf@linaro.org/ The assert was in amd64_linux_get_shadow_stack_size, but that gdbarch hook doesn't exist anymore. Also, during review of a different patch series, Andrew Burgess said=C2=B9: > We shouldn't assert on data from an outside source. This should be > either an error, or a warning if GDB is able to handle this and push > on. Which I think is a similar concern. Though in that case the outside source was a /proc file, not inferior state. >> Won't this make GDB crash with a misbehaving inferior? It could indeed m= ean >> an internal error (GDB somehow got the SSP or range wrong), but it could= also >> be (and probably more likely) an inconsistent state of the inferior. Thi= s can >> happen in a program being debugged so GDB should be able to handle it >> gracefully, and if possible provide useful information to the user. >>=20 >> Maybe turn this into an error ()? > > Do you have an example program/debug session for this? > Then it would be easier for me to write a meaningful error message. I don't. While I read the patch I just wondered whether this assert could trigger in a situation where the inferior is in a crazy or corrupted state. Maybe it tried to do some stack-switching trick and got it wrong? An error message could be direct, maybe something like "SSP doesn't point to a shadow stack memory region"... --=20 Thiago (he/him) =C2=B9 https://inbox.sourceware.org/gdb-patches/87a4ppdq5a.fsf@redhat.com/