Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Schimpe, Christina" <christina.schimpe@intel.com>
To: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: RE: [PATCH 1/9] gdb: Generalize handling of the shadow stack pointer.
Date: Mon, 17 Nov 2025 11:18:33 +0000	[thread overview]
Message-ID: <SN7PR11MB7638E8CDB0E2DC71DF388ABEF9C9A@SN7PR11MB7638.namprd11.prod.outlook.com> (raw)
In-Reply-To: <87bjlnvouh.fsf@linaro.org>

Hi Thiago,

Thanks a lot for this detailed review!
I applied most of your comments, please find my feedback to your review below.

> -----Original Message-----
> From: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
> Sent: Friday, 31 October 2025 02:32
> To: Schimpe, Christina <christina.schimpe@intel.com>
> Cc: gdb-patches@sourceware.org
> Subject: Re: [PATCH 1/9] gdb: Generalize handling of the shadow stack
> pointer.
> 
> Christina Schimpe <christina.schimpe@intel.com> writes:
> 
> > Until now, handling of the shadow stack pointer has been done in the
> > target dependent implementations of the gdbarch hook
> > 'gdbarch_shadow_stack_push'.  Also amd64 and aarch64 linux specific
> > unwinders for the shadow stack pointer are implemented.
> > In a following commit a subcommmand "backtrace shadow" of the ordinary
> 
> Too mmany m's in "subcommand".

Fixed.

> 
> > backtrace command will be added to print the shadow stack backtrace.
> > This requires more target-independent logic to handle the shadow stack
> > pointer.  To avoid that we duplicate the logic, add new source and
> > header files "shadow-stack" for the implementation of
> > shadow_stack_push and shadow stack pointer unwinding in a target-
> independent way.
> 
> <snip>
> 
> > diff --git a/gdb/aarch64-tdep.c b/gdb/aarch64-tdep.c index
> > 500ac77d75a..95af82c2632 100644
> > --- a/gdb/aarch64-tdep.c
> > +++ b/gdb/aarch64-tdep.c
> 
> As mentioned before, this change is also needed in aarch64-tdep.c to make
> this patch series work for AArch64:
> 
> diff --git a/gdb/aarch64-tdep.c b/gdb/aarch64-tdep.c index
> 95af82c26327..9e866fc319d4 100644
> --- a/gdb/aarch64-tdep.c
> +++ b/gdb/aarch64-tdep.c
> @@ -4780,6 +4780,10 @@ aarch64_gdbarch_init (struct gdbarch_info info,
> struct gdbarch_list *arches)
>    /* Register a hook for converting a memory tag to a string.  */
>    set_gdbarch_memtag_to_string (gdbarch, aarch64_memtag_to_string);
> 
> +  if (tdep->has_gcs ())
> +    /* AArch64's shadow stack pointer is the GCSPR.  */
> +    set_gdbarch_ssp_regnum (gdbarch, tdep->gcs_reg_base);
> +

Added.

>    /* ABI */
>    set_gdbarch_short_bit (gdbarch, 16);
>    set_gdbarch_int_bit (gdbarch, 32);
> 
> > -static value *
> > -amd64_linux_dwarf2_prev_ssp (const frame_info_ptr &this_frame,
> > -			     void **this_cache, int regnum)
> > -{
> > -  value *v = frame_unwind_got_register (this_frame, regnum, regnum);
> > -  gdb_assert (v != nullptr);
> > -
> > -  gdbarch *gdbarch = get_frame_arch (this_frame);
> > -
> > -  if (v->entirely_available () && !v->optimized_out ())
> > -    {
> > -      int size = register_size (gdbarch, regnum);
> > -      bfd_endian byte_order = gdbarch_byte_order (gdbarch);
> > -      CORE_ADDR ssp = extract_unsigned_integer (v->contents_all ().data (),
> > -						size, byte_order);
> > -
> > -      /* Using /proc/PID/smaps we can only check if the current shadow
> > -	 stack pointer SSP points to shadow stack memory.  Only if this is
> > -	 the case a valid previous shadow stack pointer can be
> > -	 calculated.  */
> > -      std::pair<CORE_ADDR, CORE_ADDR> range;
> > -      if (linux_address_in_shadow_stack_mem_range (ssp, &range))
> > -	{
> > -	  /* The shadow stack grows downwards.  To compute the previous
> > -	     shadow stack pointer, we need to increment SSP.  */
> > -	  CORE_ADDR new_ssp
> > -	    = ssp + amd64_linux_shadow_stack_element_size_aligned
> (gdbarch);
> > -
> > -	  /* There can be scenarios where we have a shadow stack pointer
> > -	     but the shadow stack is empty, as no call instruction has
> > -	     been executed yet.  If NEW_SSP points to the end of or before
> > -	     (<=) the current shadow stack memory range we consider
> > -	     NEW_SSP as valid (but empty).  */
> > -	  if (new_ssp <= range.second)
> 
> IIUC, the '<=' comparison above isn't preserved by this patch. This function is
> replaced by dwarf2_prev_ssp, which uses
> gdbarch_address_in_shadow_stack_memory_range for this if condition,
> whose comparison in find_addr_mem_range is:
> 
>       bool addr_in_mem_range
>         = (addr >= map.start_address && addr < map.end_address);
> 
> Is this intended?

Arg, thanks for catching that!

I think I missed that because I introduced a typo/bug in the call

	      || gdbarch_address_in_shadow_stack_memory_range (gdbarch,
							       ssp,
							       &range))

which made the unwinding work properly in case of amd64.
However, the proper fix should be to pass new_ssp to gdbarch_address_in_shadow_stack_memory_range
instead, and to implement gdbarch_top_addr_empty_shadow_stack also for amd64.

Does that make sense?

> > -	    return frame_unwind_got_address (this_frame, regnum, new_ssp);
> > -	}
> > -    }
> > -
> > -  /* Return a value which is marked as unavailable in case we could not
> > -     calculate a valid previous shadow stack pointer.  */
> > -  value *retval
> > -    = value::allocate_register (get_next_frame_sentinel_okay (this_frame),
> > -				regnum, register_type (gdbarch, regnum));
> > -  retval->mark_bytes_unavailable (0, retval->type ()->length ());
> > -  return retval;
> > -}
> 
> <snip>
> 
> > diff --git a/gdb/shadow-stack.c b/gdb/shadow-stack.c new file mode
> > 100644 index 00000000000..d153d5fc846
> > --- /dev/null
> > +++ b/gdb/shadow-stack.c
> > @@ -0,0 +1,167 @@
> > +/* Manage a shadow stack pointer for GDB, the GNU debugger.
> > +
> > +   Copyright (C) 2024-2025 Free Software Foundation, Inc.
> 
> Should this really start at 2024? According to Andrew Burgess¹:

Yes, 2024 is correct in this case since our gdb-oneapi supported bt shadow since 2024. 

> > The start date should be when the patches were first posted to the
> > list, or otherwise made publicly available (e.g. Intel specific GDB release?).
> > The end date should be updated to 2025.
> 
> Same question for other files created by this patch series.
> 
> > +   This file is part of GDB.
> > +
> > +   This program is free software; you can redistribute it and/or modify
> > +   it under the terms of the GNU General Public License as published by
> > +   the Free Software Foundation; either version 3 of the License, or
> > +   (at your option) any later version.
> > +
> > +   This program is distributed in the hope that it will be useful,
> > +   but WITHOUT ANY WARRANTY; without even the implied warranty of
> > +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > +   GNU General Public License for more details.
> > +
> > +   You should have received a copy of the GNU General Public License
> > +   along with this program.  If not, see
> > + <http://www.gnu.org/licenses/>.  */
> > +
> > +#include "defs.h"
> > +#include "arch-utils.h"
> > +#include "gdbcore.h"
> > +#include "extract-store-integer.h"
> > +#include "frame.h"
> > +#include "frame-unwind.h"
> > +#include "shadow-stack.h"
> > +
> > +enum class ssp_update_direction
> > +{
> > +  /* Update ssp towards the bottom of the shadow stack.  */
> > +  bottom = 0,
> > +
> > +  /* Update ssp towards the top of the shadow stack.  */
> > +  top
> > +};
> 
> I find the bottom/top nomenclature confusing, especially because it's
> supposed to mean the same thing whether the stack grows up or down. In
> my mind, if the stack grow down then top means "oldest element", but if the
> stack grows up, then top means "newest element".
> But in this patch it seems that top means "newest element" regardless of the
> direction of stack growth.

Yes, that was my understanding. So independent in which direction a shadow stack
grows based on the architecture/OS, top always means newest element.  But I think
it is not a problem to take one of your suggestions.

> I would suggest changing the enum names above to something that's not
> related to the vertical axis, so that their meaning will be clear regardless of
> which direction the stack grows. A few suggestions:
> shrink/grow, older/younger, outer/inner.

I'd take outer/inner and describe it as follows:

enum class ssp_update_direction
{
  /* Update ssp towards the oldest (outermost) element of the shadow
     stack.  */
  outer = 0,

  /* Update ssp towards the most recent (innermost) element of the
     shadow stack.  */
  inner
};

Is that understandable ?

> > +/* Return a new shadow stack pointer which is incremented or
> decremented
> > +   by COUNT elements dependent on DIRECTION.  */
> > +
> > +static CORE_ADDR
> > +update_shadow_stack_pointer (gdbarch *gdbarch, CORE_ADDR ssp,
> > +			     const ssp_update_direction direction) {
> > +  bool increment = (gdbarch_stack_grows_down (gdbarch))
> > +		    ? (direction == ssp_update_direction::bottom)
> > +		      : (direction == ssp_update_direction::top);
> 
> All the parentheses above are superfluous and can be removed.

Ok, fixed.

> > +  CORE_ADDR new_ssp;
> 
> This variable is unused and can be removed. Because by default GDB build
> with -Werror, this patch breaks the build with an "unused variable"
> error until patch 6 which removes this variable.

Arg, I missed that, because it's also fixed in a later patch.
I now removed it also from this patch.

> > +  if (increment)
> > +    return ssp + gdbarch_shadow_stack_element_size_aligned (gdbarch);
> > +  else
> > +    return ssp - gdbarch_shadow_stack_element_size_aligned (gdbarch);
> > +}
> > +
> > +/* See shadow-stack.h.  */
> > +
> > +void shadow_stack_push (gdbarch *gdbarch, regcache *regcache,
> 
> There's no need for a gdbarch argument. You can get it from the regcache.

Fixed.

> > +			const CORE_ADDR new_addr)
> > +{
> > +  if (!gdbarch_address_in_shadow_stack_memory_range_p (gdbarch)
> > +      || gdbarch_ssp_regnum (gdbarch) == -1)
> > +    return;
> > +
> > +  bool shadow_stack_enabled;
> > +  std::optional<CORE_ADDR> ssp
> > +    = gdbarch_get_shadow_stack_pointer (gdbarch, regcache,
> > +					shadow_stack_enabled);
> > +  if (!ssp.has_value () || !shadow_stack_enabled)
> > +    return;
> > +
> > +  const CORE_ADDR new_ssp
> > +    = update_shadow_stack_pointer (gdbarch, *ssp,
> > +				   ssp_update_direction::top);
> > +
> > +  /* If NEW_SSP does not point to shadow stack memory, we assume the
> stack
> > +     is full.  */
> > +  std::pair<CORE_ADDR, CORE_ADDR> range;
> > +  if (!gdbarch_address_in_shadow_stack_memory_range (gdbarch,
> > +						     new_ssp,
> > +						     &range))
> 
> Range isn't really needed by this function. I suggest changing
> gdbarch_address_in_shadow_stack_memory_range to allow for it to be
> nullptr and then pass nullptr here.

I agree, fixed.

> Also, the line above fits in 80 columns and doesn't need to be broken, even if
> "&range" is changed to "nullptr".

It is more than 80 columns for me.

> 
> > +    error (_("No space left on the shadow stack."));
> > +
> > +  /* On x86 there can be a shadow stack token at bit 63.  For x32,  the
> > +     address size is only 32 bit.  Always write back the full 8 bytes to
> > +     include the shadow stack token.  */
> 
> s/8 bytes/element size/

Fixed.

> 
> > +  const int element_size
> > +    = gdbarch_shadow_stack_element_size_aligned (gdbarch);
> > +
> > +  const bfd_endian byte_order = gdbarch_byte_order (gdbarch);
> > +
> > +  write_memory_unsigned_integer (new_ssp, element_size, byte_order,
> > +				 (ULONGEST) new_addr);
> > +
> > +  regcache_raw_write_unsigned (regcache,
> > +			       gdbarch_ssp_regnum (gdbarch),
> > +			       new_ssp);
> 
> The line above fits in 80 columns and doesn't need to be broken.

I count 81 columns and there is also a soft limit of 74 characters:

https://sourceware.org/legacy-ml/gdb-patches/2014-01/msg00216.html

So I'll keep it as is, if that's fine for you.

> 
> > +}
> > +
> > +/* See shadow-stack.h.  */
> > +
> > +value *
> > +dwarf2_prev_ssp (const frame_info_ptr &this_frame, void **this_cache,
> > +		 int regnum)
> > +{
> > +  value *v = frame_unwind_got_register (this_frame, regnum, regnum);
> > +  gdb_assert (v != nullptr);
> > +
> > +  gdbarch *gdbarch = get_frame_arch (this_frame);
> > +
> > +  if (gdbarch_address_in_shadow_stack_memory_range_p (gdbarch)
> > +      && v->entirely_available () && !v->optimized_out ())
> > +    {
> > +      const int size = register_size (gdbarch, regnum);
> > +      bfd_endian byte_order = gdbarch_byte_order (gdbarch);
> > +      CORE_ADDR ssp = extract_unsigned_integer
> > +	(v->contents_all ().data (), size, byte_order);
> > +
> > +      /* Only if the current shadow stack pointer SSP points to shadow
> > +	 stack memory a valid previous shadow stack pointer can be
> > +	 calculated.  */
> > +      std::pair<CORE_ADDR, CORE_ADDR> range;
> > +      if (gdbarch_address_in_shadow_stack_memory_range (gdbarch, ssp,
> > +							&range))
> 
> This line fits in 80 columns and doesn't need to be broken.

In this case I'll take your suggestion, since it looks much nicer unbroken. 😊

> 
> > +	{
> > +	  /* Note that a shadow stack memory range can change, due to
> > +	     shadow stack switches for instance on x86 for an inter-
> > +	     privilege far call or when calling an interrupt/exception
> > +	     handler at a higher privilege level.  Shadow stack for
> > +	     userspace is supported for amd64 linux starting with
> > +	     Linux kernel v6.6.  However, shadow stack switches are not
> > +	     supported due to missing kernel space support.  We therefore
> > +	     implement this unwinder without support for shadow stack
> > +	     switches for now.  */
> > +	  const CORE_ADDR new_ssp
> > +	    = update_shadow_stack_pointer (gdbarch, ssp,
> > +					   ssp_update_direction::bottom);
> > +
> > +	  /* On x86, if NEW_SSP points to the end of RANGE, it indicates
> > +	     that NEW_SSP is valid, but the shadow stack is empty.  In
> > +	     contrast, on ARM's Guarded Control Stack, if NEW_SSP points
> > +	     to the end of RANGE, it means that the shadow stack pointer
> > +	     is invalid.  */
> > +	  bool is_top_addr_empty_shadow_stack
> > +	    = gdbarch_top_addr_empty_shadow_stack_p (gdbarch)
> > +	      && gdbarch_top_addr_empty_shadow_stack (gdbarch, new_ssp,
> > +range);
> > +
> > +	  /* Check whether the new SSP is valid.  Depending on the
> > +	     architecture, this may rely on both
> > +	     IS_TOP_ADDR_EMPTY_SHADOW_STACK and the return value of
> > +	     gdbarch_address_in_shadow_stack_memory_range, or on the
> > +	     latter only.  */
> > +	  if (is_top_addr_empty_shadow_stack
> 
> Considering that, as previously mentioned,
> gdbarch_address_in_shadow_stack_memory_range uses '<' rather than '<='
> in the memory range check, AArch64 doesn't need
> gdbarch_top_addr_empty_shadow_stack.

Agree, but for amd64 I need it... (as described before).

> 
> The way this if condition is written, I think it's x86_64 that would need to
> provide an gdbarch_top_addr_empty_shadow_stack implementation.
> I'm surprised it doesn't.

As described before, I missed to pass new_ssp instead of ssp, which made this
code work for amd64.  But it's not correct, and I need
gdbarch_top_addr_empty_shadow_stack.
Thanks again for catching that!

> > +	      || gdbarch_address_in_shadow_stack_memory_range (gdbarch,
> > +							       ssp,
> 
> Shouldn't this argument be new_ssp?

Already discussed before.

> 
> > +							       &range))
> > +	    return frame_unwind_got_address (this_frame, regnum, new_ssp);
> > +	}
> > +    }
> > +
> > +  /* Return a value which is marked as unavailable, in case we could not
> > +     calculate a valid previous shadow stack pointer.  */
> > +  value *retval
> > +    = value::allocate_register (get_next_frame_sentinel_okay (this_frame),
> > +				regnum, register_type (gdbarch, regnum));
> > +  retval->mark_bytes_unavailable (0, retval->type ()->length ());
> > +  return retval;
> > +
> 
> Spurious empty line added here.

Fixed.

> > +}
> > diff --git a/gdb/shadow-stack.h b/gdb/shadow-stack.h new file mode
> > 100644 index 00000000000..5c3ba80974e
> > --- /dev/null
> > +++ b/gdb/shadow-stack.h
> > @@ -0,0 +1,39 @@
> > +/* Definitions to manage a shadow stack pointer for GDB, the GNU
> debugger.
> > +
> > +   Copyright (C) 2024-2025 Free Software Foundation, Inc.
> > +
> > +   This file is part of GDB.
> > +
> > +   This program is free software; you can redistribute it and/or
> > + modify
> > +
> > +   it under the terms of the GNU General Public License as published by
> > +   the Free Software Foundation; either version 3 of the License, or
> > +   (at your option) any later version.
> > +
> > +   This program is distributed in the hope that it will be useful,
> > +   but WITHOUT ANY WARRANTY; without even the implied warranty of
> > +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > +   GNU General Public License for more details.
> > +
> > +   You should have received a copy of the GNU General Public License
> > +   along with this program.  If not, see
> > + <http://www.gnu.org/licenses/>.  */
> > +
> > +#ifndef GDB_SHADOW_STACK_H
> > +#define GDB_SHADOW_STACK_H
> > +
> > +/* If shadow stack is enabled, push the address NEW_ADDR on the
> shadow
> > +   stack and update the shadow stack pointer accordingly.  */
> > +
> > +void shadow_stack_push (gdbarch *gdbarch, regcache *regcache,
> 
> Recently, the project has been trying to make the header files contain all the
> headers and definitions that they need, for the benefit of IDE and language
> server users, so that these tools don't emit spurious errors when showing a
> header file.

Ah, ok I wasn't aware. Do you have a link for that ? I think I cannot follow 100 %.

> In this case, clangd is complaining here that regcache is unknown. There's no
> need to include regcache.h just for it, just adding a "class regcache" forward
> declaration at the beginning of the file is enough.
> 
> > +			const CORE_ADDR new_addr);

Ok, added!

> > +
> > +/* Unwind the previous shadow stack pointer of THIS_FRAME's shadow
> stack
> > +   pointer.  REGNUM is the register number of the shadow stack pointer.
> > +   Return a value that is unavailable in case we cannot unwind the
> > +   previous shadow stack pointer.  Otherwise, return a value containing
> > +   the previous shadow stack pointer.  */
> > +
> > +value * dwarf2_prev_ssp (const frame_info_ptr &this_frame,
> 
> The space after "value *" should be removed.

Fixed.

> 
> > +			 void **this_cache, int regnum);
> > +
> > +#endif /* GDB_SHADOW_STACK_H */
> --
> Thiago
> 
> ¹ https://inbox.sourceware.org/gdb-patches/87ldo6c84t.fsf@redhat.com/


Christina
Intel Deutschland GmbH
Registered Address: Dornacher Straße 1, 85622 Feldkirchen, Germany
Tel: +49 89 991 430, www.intel.de
Managing Directors: Harry Demas, Jeffrey Schneiderman, Yin Chong Sorrell
Chairperson of the Supervisory Board: Nicole Lau
Registered Seat: Munich
Commercial Register: Amtsgericht München HRB 186928

  reply	other threads:[~2025-11-17 11:19 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-23 11:18 [PATCH 0/9] Add new command to print the shadow stack backtrace Christina Schimpe
2025-09-23 11:18 ` [PATCH 1/9] gdb: Generalize handling of the shadow stack pointer Christina Schimpe
2025-10-31  1:31   ` Thiago Jung Bauermann
2025-11-17 11:18     ` Schimpe, Christina [this message]
2025-11-26  4:19       ` Thiago Jung Bauermann
2025-12-30 10:39         ` Schimpe, Christina
2025-09-23 11:18 ` [PATCH 2/9] gdb: Refactor 'stack.c:print_frame' Christina Schimpe
2025-10-03 20:05   ` Tom Tromey
2025-09-23 11:18 ` [PATCH 3/9] gdb: Introduce 'stack.c:print_pc' function without frame argument Christina Schimpe
2025-10-03 19:56   ` Tom Tromey
2025-09-23 11:18 ` [PATCH 4/9] gdb: Refactor 'find_symbol_funname' and 'info_frame_command_core' in stack.c Christina Schimpe
2025-10-03 19:55   ` Tom Tromey
2025-09-23 11:18 ` [PATCH 5/9] gdb: Refactor 'stack.c:print_frame_info' Christina Schimpe
2025-10-03 20:03   ` Tom Tromey
2025-09-23 11:18 ` [PATCH 6/9] gdb: Implement 'bt shadow' to print the shadow stack backtrace Christina Schimpe
2025-09-23 11:47   ` Eli Zaretskii
2025-09-25 11:06     ` Schimpe, Christina
2025-09-25 13:19       ` Eli Zaretskii
2025-09-25 14:58         ` Simon Marchi
2025-09-26  7:45           ` Schimpe, Christina
2025-10-29 15:05             ` Schimpe, Christina
2025-10-29 15:28               ` Guinevere Larsen
2025-11-03 19:47                 ` Schimpe, Christina
2025-11-04 11:53                   ` Guinevere Larsen
2025-11-05 16:33                     ` Schimpe, Christina
2025-10-13  1:17       ` Thiago Jung Bauermann
2025-10-13  7:19         ` Schimpe, Christina
2025-10-31  4:39           ` Thiago Jung Bauermann
2025-11-06 14:23             ` Schimpe, Christina
2025-10-03 20:15   ` Tom Tromey
2025-10-12 19:45     ` Schimpe, Christina
2026-02-19 17:24       ` Tom Tromey
2026-03-02 12:24         ` Schimpe, Christina
2025-10-31  4:02   ` Thiago Jung Bauermann
2025-11-17 20:14     ` Schimpe, Christina
2025-11-26  4:07       ` Thiago Jung Bauermann
2025-11-26 16:29         ` Thiago Jung Bauermann
2026-01-22 17:04           ` Schimpe, Christina
2026-03-06  2:35             ` Thiago Jung Bauermann
2026-01-15 14:05         ` Schimpe, Christina
2025-09-23 11:18 ` [PATCH 7/9] gdb: Provide gdbarch hook to distinguish shadow stack backtrace elements Christina Schimpe
2025-09-23 11:49   ` Eli Zaretskii
2025-09-25 11:10     ` Schimpe, Christina
2025-11-02 21:20       ` Thiago Jung Bauermann
2025-11-12 17:28         ` Schimpe, Christina
2025-11-16 18:39           ` Thiago Jung Bauermann
2025-11-17 11:51             ` Schimpe, Christina
2025-09-23 11:18 ` [PATCH 8/9] gdb: Implement the hook 'is_no_return_shadow_stack_address' for amd64 linux Christina Schimpe
2025-11-26  4:22   ` Thiago Jung Bauermann
2025-09-23 11:18 ` [PATCH 9/9] gdb, mi: Add -shadow-stack-list-frames command Christina Schimpe
2025-09-23 11:53   ` Eli Zaretskii
2025-09-25 11:32     ` Schimpe, Christina
2025-10-03 20:17   ` Tom Tromey
2025-10-12 19:54     ` Schimpe, Christina
2025-10-13  0:06       ` Thiago Jung Bauermann
2025-11-26  4:26   ` Thiago Jung Bauermann
2026-01-22 17:01     ` Schimpe, Christina
2026-03-06  2:44       ` Thiago Jung Bauermann
2025-09-25 11:46 ` [PATCH 0/9] Add new command to print the shadow stack backtrace Schimpe, Christina
2025-10-08  1:46   ` Thiago Jung Bauermann
2025-10-13  1:18     ` Thiago Jung Bauermann
2025-10-13  6:34       ` Schimpe, Christina
2025-10-29 14:52         ` Schimpe, Christina
2025-10-31  0:47           ` Thiago Jung Bauermann
2025-12-30 10:16             ` Schimpe, Christina
2026-03-06  2:30               ` Thiago Jung Bauermann
2026-03-12  9:53                 ` Schimpe, Christina

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SN7PR11MB7638E8CDB0E2DC71DF388ABEF9C9A@SN7PR11MB7638.namprd11.prod.outlook.com \
    --to=christina.schimpe@intel.com \
    --cc=gdb-patches@sourceware.org \
    --cc=thiago.bauermann@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox