From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id WRVlGcQR/GkOgxwAWB0awg (envelope-from ) for ; Thu, 07 May 2026 00:15:00 -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=lHXxiuLu; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 643A81E093; Thu, 07 May 2026 00:15:00 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.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,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 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 1500D1E093 for ; Thu, 07 May 2026 00:14:59 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8EDC34BA23CE for ; Thu, 7 May 2026 04:14:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8EDC34BA23CE 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=lHXxiuLu Received: from mail-dl1-x122f.google.com (mail-dl1-x122f.google.com [IPv6:2607:f8b0:4864:20::122f]) by sourceware.org (Postfix) with ESMTPS id 4306F4BA2E10 for ; Thu, 7 May 2026 04:14:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4306F4BA2E10 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 4306F4BA2E10 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::122f ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1778127264; cv=none; b=WCdKApqqt/X+X8Y4fttvIjbKr43G1ibA60K097urtQnQcbcZLQmWfUAVd3EqVwJPVuwU9lOQLW/Xwg1rp/AXPeCPqYEPHiTRSiLAYFisWTk/NaT08SeuIankl1a9pl7Wx3ZSr8V1asWOFlU0zedZt+pWP4PMvSyP3aap/lECddA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1778127264; c=relaxed/simple; bh=WJ8KY5P+YYoaPAGmNn9rwANrsb8fnSPkJ9GIZCmYDwM=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=r0jCjyHTzr2In/bUX6EHhAmWa6BdeqRRgRqaNyGAi5fQBkHZZ+KG0dEuTNrLLJtDDN0aciz5lc9KUGQja1Gcij3WcAHe17sq7C4W1CxESZwoaBl8HZcvvmCe5kT0gUGn2WF4qjGb05bxI3npYgFQRkr/RdPCjmn0qeUaTJu33wc= 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=lHXxiuLu DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4306F4BA2E10 Received: by mail-dl1-x122f.google.com with SMTP id a92af1059eb24-13246950f3cso117852c88.1 for ; Wed, 06 May 2026 21:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1778127263; x=1778732063; 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=+2/zZk+Gn1u3lVt+mTu0RwuujstKU3IKwpdJUNV7El0=; b=lHXxiuLu3OJfqger3a0CaXKerNMZQ/W/TiQxh/nXcgOn1V489w6gBVvENTV4Zhex3x /LIQ/gp2Oe1U995sY+jtpEBDiVA/F2Y9v8LVaEXIJqSSNx+SiqDoGHO70GPs89CtORFU di4GiKhB3sw6hvQjtJsRktwZOd7F19c1pnXRp/P75AXUZiquLZxmgk2b5rCo13XQd363 PoB9CH08ezWWE1xWOS7z2l6WJvtK5Ttxc0cwJRfvem03ViTHXmY1rmLk86hiCmu6EKf8 ATmW3Dk981/0LArxPeyYRtC4IfjC1X6/g8qpJt184Wb4WyrHOY6R0rOdLH06Mb9/O1C6 XqdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778127263; x=1778732063; 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=+2/zZk+Gn1u3lVt+mTu0RwuujstKU3IKwpdJUNV7El0=; b=V1+sV8j5YqN0aPjhg4/9y0YT3adkTa5Fu/2rlGjHHROgna695vr/ZLNjzm0pGwSGkJ q+/aSqaOK/k/Iio0xmdScHRTlX6R117VhAURIlSS6Z2z/F4/n1USqYiu4FPx2rpt44Pw tr0KAZ9C4dbCGOqEbPv9BM03i03qQbf/cUs515408+B1lBbWzrRZ50lI9xLkX0Vs4XC/ OQjQh+fZmGNVyNdNGo/IUDcaq+O7PLg6Md0SM0D5Hx8cOGd7AByJQijIXtQTAHhMmd43 cqdEAiCfZQnKaUfO4SWLXMR6RKw0KCMz6OUUPgueJ/GDPBAUVWY58Q7IjZK5ot8TUMX+ Y1Rw== X-Gm-Message-State: AOJu0YyFH851Ua2g6XB9cd7TMfSdu3y3sR9hBJNxtwS2O1MRTOj1MbvF z6NN4slw/AzGzpd/NqAPwdz1MP3RIMSoMJaWPRSnqS8uar0R9OiUzgdvkj8wAeha6D55lTD4rd8 b6zgy X-Gm-Gg: AeBDieuvsPdQn4MQplYabcgy71PFBvIW7LCOmxZgtFwz+86xpWyGaT2gHrWa2D1GdfC cetAiRUzwPbD/Z0SC+ghbtjrwsmXdClPrxpg+r2NTMut9p5HFNTtwnsHy44NnPX4rs7xzJ1fhxE HITYqle38FAdx3rOmCgEj4Ygpi6vCtYejV2yluWbAIXdDrlZKCICkGxq/RvhnL1jfdgimiGvb1R 7B3zh+NpTIg8GQ7R2arPFstWqq+fBahieUSfNfyHNb8+TqZic4FFP+iu2Hct61d613hQmdi2DRq Pnmrfqs39L9SXPtPxbAfnZxIaXNiKHQ0VVJqFBwf/8N8CC1XqoozYuj5E9B2X0CUK2L318HU9UW hHWKJ42pQb5SifUaJf3F2vPUPirVJUx5YPZcBiNKZgJQaAS+b3T+LIsTwJQmC1v494kBoaPwrTQ BOruUIijZ2gS++kSVYbH7wkGKJRw== X-Received: by 2002:a05:7022:b8e:b0:12f:1f67:e743 with SMTP id a92af1059eb24-1318eb50ae6mr3541085c88.40.1778127262924; Wed, 06 May 2026 21:14:22 -0700 (PDT) Received: from localhost ([2804:14d:5c5b:48de::33b7]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-1320f16b189sm4727956c88.12.2026.05.06.21.14.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 May 2026 21:14:22 -0700 (PDT) From: Thiago Jung Bauermann To: Christina Schimpe Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v2 0/9] Add new command to print the shadow stack backtrace In-Reply-To: <20260123080532.878738-1-christina.schimpe@intel.com> (Christina Schimpe's message of "Fri, 23 Jan 2026 08:05:22 +0000") References: <20260123080532.878738-1-christina.schimpe@intel.com> User-Agent: mu4e 1.14.1; emacs 30.2 Date: Thu, 07 May 2026 01:14:19 -0300 Message-ID: <87se8397qc.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, I had a look at the review threads for v1 and v2 of this patch series, and I think the discussion below cover the loose ends that were still unaddressed. Please let me know if I am missing anything, or if there anything else you want to bring up before posting v3. Christina Schimpe writes: > Opens: Hoisting up the lines below from your email because in this reply I need to reference them first: > My latest reply regarding items 1-4 can be found here: > https://sourceware.org/pipermail/gdb-patches/2026-January/224054.html I never replied to that email (sorry), so I'll paste below between "----" markers the parts corresponding to the open items, and finally reply to them here. Hopefully it's less confusing than resurrecting that thread. > 1) Thiago suggested changing the frame numbering so that it always starts > at #1, since for the shadow stack we don't have frame #0 printed by the > normal backtrace. > 2) Or, consider printing frame arguments and frame #0 similarly to what > the normal backtrace does. Here are the parts about 1 and 2: ---- > Thinking about this again I wonder if it's a good idea to start the > numbering with #1. Besides frame #0, there are multiple reasons why > the numbering of the normal backtrace is out-of-sync with the shadow > stack backtrace, e.g. inline calls, tail calls or python frame > filters. Indeed this is true. There are many cases where the numbers will be out of sync (I hadn't considered Python frame filters!). I still think it's less confusing if the shadow stack starts numbering at 1. But that is because I think it makes sense to try to keep the regular stack backtrace and the shadow stack backtrace similar when it's not too hard to do so. However: my understanding is that your inclination is to make the shadow backtrace faithfully present the actual contents of the shadow stack as they are in shadow stack memory. That makes a lot of sense too, and I can agree with that. So to be honest I have a preference to start numbering the shadow stack frames at 1, but it's not a strong one. If you prefer to start numbering at 0, that is fine by me. > Another option is to add the original #0 frame using the current > $pc. But what I don=E2=80=99t like about this, is that the user could be > confused and think that $pc is on the shadow stack. I agree that it is confusing. I prefer not to show the current $pc in the shadow stack backtrace. ---- In that email you also said (in the part where we were talking about line numbers displayed for the return address): > ...but since the overall direction is to align more with the normal > backtrace, I agree with you here. =F0=9F=98=8A I'd like to comment that it's the "overall direction" in the sense that it's the direction my comments point to, but it's just my opinion. I think it also makes sense to make "bt -shadow" more closely reflect the actual contents of the shadow stack. So if regarding the alternatives we are considering for the output of "bt -shadow" (stack frame numbering, printing or not of function arguments, printing of line numbers and so on) you think it's better to choose the other option, feel free to disagree and do it the way you think is better. > 3) For non-return addresses on the shadow stack, we want to display a str= ing, > as already implemented for signals. For inferior calls, we also want to > display . The return address for inferior calls > is pushed onto the shadow stack by GDB, but we currently don=E2=80=99t ha= ve a way > to distinguish this address from normal return addresses. Thiago suggest= ed > pushing the return address together with a marker, but it=E2=80=99s still= unclear > how this marker should look like. In AArch64 GCS, we can have "cap" entries which are markers in the stack. Bits 63-12 of the entry have to be the address of the cap entry itself, but bits 11-0 can be arbitrary values. I think the equivalent in x86 shadow stacks would be an entry with the 63 bit set. Can the other bits have an arbitrary value? If so, before we push the return address for the inferior call, we could push a cap entry / data entry with a magic value reserved for GDB to mark dummy shadow stack frames. Then GDB would know that the next entry after it would be the return address for the inferior call. Then when printing a shadow stack frame, we can check whether the entry immediately preceding it has the magic value and print "". The parts from your latest reply: ---- >> 3. We can change GDB to also put a marker in the shadow stack when it do= es >> an inferior function call, and look for it in the shadow stack. > > We call shadow_stack_push in generic GDB code. Do you think we could find= an > architecture independent marker ? > Then we can also return true with the gdbarch hook is_no_return_address a= nd > set the string to . I don't think we can find an arch independent marker. In x86, I believe the marker would have to have bit 63 set. While in AArch64 bits 63-12 of the entry need to have the same value as the address of the entry itself. Only bits 11-0 of the entry are free to have an arbitrary token value. > I am just not sure if the linux kernel ever decides to extend its functio= nality for > CET shadow stack and uses the bits that we use for our marker. > In theory the linux kernel could decide to support 32bit shadow stack fo= r x86 > one day, or supervisor shadow stacks =E2=80=93 and I am not sure what bit= s the kernel > might set in the shadow stack elements to support this. > I wonder if we should discuss this in the linux kernel mailing lists. Good idea, it makes sense to coordinate with the kernel people to see if we can/should reserve a magic token/data value to use in GDB for dummy shadow stack frames. I'll ask the arm64 kernel people to see if they have an opinion on the topic. ---- > 4) For signals, we also want to print , as in the > normal backtrace. Since in this case we have a normal return address on > the shadow stack, it=E2=80=99s not yet clear to me how to implement this. On AArch64, when calling a signal handler the kernel pushes a signal cap entry where bits 11-0 have the value 0. So to recognize the shadow stack entry which should be labelled "", we just need to look at the older entry and see if it's the signal cap entry. I believe x86 also pushes a data entry in the shadow stack when calling the signal handler (the sigframe token), so couldn't GDB look for it and conclude that the entry following it is the "" entry? > 5) Remove annotations. Based on Tom's input, I think we should drop them, > but I am not yet sure how exactly. Please see my latest response here: > https://sourceware.org/pipermail/gdb-patches/2025-October/221652.html >From that thread I understood that you can simply not add annotations to "bt -shadow" output. Or =E2=80=94 and this is probably me reading between the lines =E2=80=94 if= annotations appear because you are reusing functions from the regular backtrace command and they aren't adequate, then you can ignore the problem because annotations are long deprecated and not expected to work for new functionality. --=20 Thiago