From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id OoeDAzDLB2mT5BoAWB0awg (envelope-from ) for ; Sun, 02 Nov 2025 16:20:48 -0500 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=JeHBLLt9; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id EB05C1E0BC; Sun, 02 Nov 2025 16:20:47 -0500 (EST) 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 server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (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 AF28A1E04C for ; Sun, 02 Nov 2025 16:20:46 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2CA883858409 for ; Sun, 2 Nov 2025 21:20:46 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2CA883858409 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=JeHBLLt9 Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) by sourceware.org (Postfix) with ESMTPS id 44CDC3858D33 for ; Sun, 2 Nov 2025 21:20:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 44CDC3858D33 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 44CDC3858D33 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::52e ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1762118407; cv=none; b=KqmpSau6V7eN3OaSLLgzpBqb8hGLiv9okB3HsUNw1U64fKC2Put9SRm9/qfgMxImBLmu1fMsUyQvoQMPdzE6uctfKU4zdK0m0zIKl5499r3MDMt6YVrnJwBH5ukOX6L8cEe6RRkXT5H8SwTCSWuTWFboWAkdJxEJTpvH2EVNj/c= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1762118407; c=relaxed/simple; bh=DF6rme0cfm9nYkyhtk8YgcIcG1QQeUS/osMHpaHPINY=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=dlm0XshWtMMKNnwhs4enZIRTadHEeEvaOxk5JbFXP23JXxnfr7FAXsVmgQx9YOsnWKuvKrHQ2fyFnyMxZMIzI+0DpO5FJs2uPJhl1slsyUPSakC5FJPKmGABsc4odEySGBr3w4GUbb+fVqs+p2eGyI8EKdepnqQk06WrHGv2qQE= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 44CDC3858D33 Received: by mail-pg1-x52e.google.com with SMTP id 41be03b00d2f7-b5579235200so2714159a12.3 for ; Sun, 02 Nov 2025 13:20:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1762118406; x=1762723206; darn=sourceware.org; h=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=eC/HPQlEpv5hdCir2BOwa6Z0IrHsIfRshMTj7vicOHA=; b=JeHBLLt9KTY7+gUgd+jszWJ8vkvLIQwcdAcIvnaU4fVz409+NTN7mqROQgCJsLynr8 ClJRqhnXMcXuPVOp/B3Sjccl/vS4DlLthnSnwDpLfjrwYJmfQOGCeSg94Wtv8gztBXHJ WFNj3IAaznLxWNcFZbo9NVLzG2HiXXt+Tk2qoDosFYa3QCQl/Wys7YJugSrMVcQLixDJ CI60FCUY4rlTAJxQQkG/DxQtH/ZJTpVVRjdgzgjF7wgR4WsOm7BkWgYNumxhfiNpXETq ogQ1Zt8gcmXEqsaafNuSH2b2kKaz7NFI0YewjO3S86UMpkmJU8MF5VviOkOrowFjt0xy g0cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762118406; x=1762723206; h=mime-version:message-id:date:user-agent:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=eC/HPQlEpv5hdCir2BOwa6Z0IrHsIfRshMTj7vicOHA=; b=fvS+M0UQrw9cfdHVO7Ez+FO6y5bnqu/+C4XE2uMj+94RGMPdFa8+pJA4h9LRiKptVx ii1uKvbDroVKKTuiA7PLrUKod0dFltCHl6qDFi9Tan7DJO3K3meiaLyWA85CcVdbIHzK oKgnIDTnElDNraUneDOHiiztDMVfsIyTUQrXuQNOnqZLQErvzVHXfGEkG7JYLnSQ4/r6 QDhbXP5rhcKfwLzY6VPYN2EKvyVfOZG9wUbmn8cjRp5vRkt10yN+HzoRaCQNgcoqlfi9 3cFVZvwWpTLCGTCLFG/xT5OlGwTRbFjch6S8j19attlQX36QBNMoxLsBp+6F7FDIMxUE v6gw== X-Forwarded-Encrypted: i=1; AJvYcCUOmI6pBkwQvKA+9/OxwHsMimWRlxkKFEBJx06XI7N9MncPaTp2WVXk1Cbd01veTmqqiWm6s7EVbKa56w==@sourceware.org X-Gm-Message-State: AOJu0YxaYCG0DUj+rdr/ty2UWxgeloOc5j4dW9/ro1bDWRYXijCNeGjL rhIgnI1+/sTz6stvPg7jE/Un1RYoa+bYUnd4Jfo85ng1m4dxP7XVAcYvIHAvtYVg7KeQbTi6D/C 8WtDMrWg= X-Gm-Gg: ASbGncsTQ4bYwPjTKpoAaNoFZL4GALebILZ/UnAb9SrW7w8VlgS37efcpFouHT8G32N vTxZq/ZEtJvvz1bcG8IvNSdYlp2Msodp7fmv3/DbiXgz6V8HjN9PYotVHpNRvXvy/9jaticv3R4 EIDVGTI7D6ygsyu4T4P+xKZe5Dlg8b/z6OhuOrrot/VbAmVQngm4d0rdLbN2bPtTYy9+4iY9p9w abM1dCxW5p06drFpWEIbMqD6T8duBGlwa1Hg22PvYWbY5wzCDVP9isQF6p7khOAUKY5FaY7CHAo VxfYPR83xo4EDvj1amYgi94IknctiNmFsyh5bfkWHMRdVWGlUnLZbugoeQjzsA+c8Br47em/Agm JQuX+bV4rUHiTtrl2nRU+/EB7mZS1cnwvRu+AvsJRHBOFEsBMJerkERjK4+Wvmx0oVlBHMhO9BO bguK+HXlWg/AU2cS+SBN4= X-Google-Smtp-Source: AGHT+IHLwInFu8X9UgMkGme2RqjUgLxksu+CnkKUQkzp221u8w+wNBTm0YJYaVhR7iqHDe9WWSVVWQ== X-Received: by 2002:a17:902:f64c:b0:295:1a5c:efff with SMTP id d9443c01a7336-2951a5cf611mr131547695ad.14.1762118406214; Sun, 02 Nov 2025 13:20:06 -0800 (PST) Received: from localhost ([201.140.213.137]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-29526871023sm93831065ad.13.2025.11.02.13.20.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 02 Nov 2025 13:20:05 -0800 (PST) From: Thiago Jung Bauermann To: "Schimpe, Christina" Cc: Eli Zaretskii , "gdb-patches@sourceware.org" Subject: Re: [PATCH 7/9] gdb: Provide gdbarch hook to distinguish shadow stack backtrace elements. In-Reply-To: (Christina Schimpe's message of "Thu, 25 Sep 2025 11:10:14 +0000") References: <20250923111842.4091694-1-christina.schimpe@intel.com> <20250923111842.4091694-8-christina.schimpe@intel.com> <86wm5pcrs0.fsf@gnu.org> User-Agent: mu4e 1.12.11; emacs 30.2 Date: Sun, 02 Nov 2025 18:20:02 -0300 Message-ID: <87cy60p1x9.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain 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, "Schimpe, Christina" writes: >> -----Original Message----- >> From: Eli Zaretskii >> Sent: Tuesday, September 23, 2025 1:50 PM >> To: Schimpe, Christina >> Cc: gdb-patches@sourceware.org >> Subject: Re: [PATCH 7/9] gdb: Provide gdbarch hook to distinguish shadow >> stack backtrace elements. >> >> > From: Christina Schimpe >> > Date: Tue, 23 Sep 2025 11:18:40 +0000 >> > >> > On x86 with CET there can be elements on the shadow stack which are >> > not return addresses. In this case, we just want to print the element >> > itself in the shadow stack backtrace, but no further information. >> > >> > Provide a gdbarch hook to distinguish between return and non-return >> > addresses and use it to print the shadow stack backtrace as described >> > above. >> > --- >> > gdb/doc/gdb.texinfo | 19 ++++++++++++ >> > gdb/gdbarch-gen.c | 32 ++++++++++++++++++++ >> > gdb/gdbarch-gen.h | 15 +++++++++ >> > gdb/gdbarch.h | 1 + >> > gdb/gdbarch_components.py | 17 +++++++++++ >> > gdb/shadow-stack.c | 64 +++++++++++++++++---------------------- >> > gdb/shadow-stack.h | 37 ++++++++++++++++++++++ >> > 7 files changed, 148 insertions(+), 37 deletions(-) >> >> Thanks. >> >> > diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo index >> > ebda4546b58..a0fde385a8e 100644 >> > --- a/gdb/doc/gdb.texinfo >> > +++ b/gdb/doc/gdb.texinfo >> > @@ -8887,6 +8887,25 @@ This is how a shadow stack backtrace looks like >> on amd64: >> > @end group >> > @end smallexample >> > >> > +There can be elements on the shadow stack which are not return >> > +addresses, for example on x86 with the Intel Control-Flow Enforcement >> > +Technology (@xref{CET}). In case of signals, the old shadow stack >> > +pointer is pushed >> ^ >> A cross-reference is missing here. > > Thanks will fix. > >> > +in a special format with bit 63 set. For such shadow stack elements, >> > +the shadow stack frame just contains the level and the address on the >> > +shadow stack, as shown in the following example by frame 1: >> > + >> > +@smallexample >> > +@group >> > +(gdb) bt shadow 4 >> > +#0 0x00007ffff7c54d90 in __restore_rt from /lib64/libc.so.6 >> > +#1 0x80007ffff79fffd8 >> > +#2 0x00007ffff7c54ce6 in __GI_raise at ../sysdeps/posix/raise.c:27 >> > +#3 0x000000000040115d in main at /tmp/amd64-shadow-stack- >> signal.c:32 >> > +(More shadow stack frames follow...) >> > +@end group >> > +@end smallexample >> >> Would it make sense to show something like "", instead of a >> frame with only an address? > > Yeah, this is a good idea, I wondered about a similar thing actually but wanted to discuss > the general direction for handling those specific elements on the shadow stack first. > Maybe there are more options on other architectures that we have to consider. > Let's wait for more feedback on this, I added Thiago again in cc here. Yes, I would like to show a "" message in the corresponding shadow stack entry, as is done in the regular stack: (gdb) bt #0 handler (signo=10) at aarch64-gcs-signal.c:59 #1 #2 __pthread_kill_implementation (threadid=281474842447584, signo=signo@entry=10, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 #3 0x0000fffff7e77670 in __pthread_kill_internal (signo=10, threadid=) at ./nptl/pthread_kill.c:78 #4 0x0000fffff7e2cb3c in __GI_raise (sig=10) at ../sysdeps/posix/raise.c:26 #5 0x0000aaaaaaaa0b24 in main () at aarch64-gcs-signal.c:96 Here is the corresponding GCS backtrace: (gdb) bt shadow #0 0x0000fffff7ffa85c in __kernel_rt_sigreturn #1 0x0000fffff7bff000 in ?? #2 0x0000fffff7e2cb3c in __GI_raise at ../sysdeps/posix/raise.c:27 #3 0x0000aaaaaaaa0b24 in main at aarch64-gcs-signal.c:99 In this example "" message would replace the VDSO function name in entry #0. Also note that it's an actual return address but we still want to show a custom message for it. Finally, notice that there's GCS entry #1, which isn't a return address. It's a "cap record", which marks that the stack is currently not in use. When a signal is delivered, the kernel pushes two entries to the thread's GCS: first the cap record, then the address to the signal trampoline (__kernel_rt_sigreturn). For this entry, I'd like to show "". One suggestion to handle that is to make do_print_shadow_stack_frame_info call a new hook gdbarch_print_shadow_stack_frame_info which would allow the architecture to print the shadow stack frame however it wants. If the hook returns false, then do_print_shadow_stack_frame_info would print the information itself, as it does in your patch. What do you think? -- Thiago