Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Schimpe, Christina" <christina.schimpe@intel.com>
To: 'Luis' <luis.machado.foss@gmail.com>,
	Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Cc: Andrew Burgess <aburgess@redhat.com>,
	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: RE: [PATCH v5 07/12] gdb: amd64 linux coredump support with shadow stack.
Date: Mon, 11 Aug 2025 11:52:46 +0000	[thread overview]
Message-ID: <SN7PR11MB7638ED439EF2451568A19056F928A@SN7PR11MB7638.namprd11.prod.outlook.com> (raw)
In-Reply-To: <40bebcad-2fcf-4340-82bb-2694be2af12c@gmail.com>

Hi Luis and Thiago,

> -----Original Message-----
> From: Luis <luis.machado.foss@gmail.com>
> Sent: Wednesday, August 6, 2025 10:52 PM
> To: Thiago Jung Bauermann <thiago.bauermann@linaro.org>; Schimpe,
> Christina <christina.schimpe@intel.com>
> Cc: Andrew Burgess <aburgess@redhat.com>; gdb-
> patches@sourceware.org; luis.machado@arm.com
> Subject: Re: [PATCH v5 07/12] gdb: amd64 linux coredump support with
> shadow stack.
> 
> On 8/5/25 05:29, Thiago Jung Bauermann wrote:
> > Hello,
> >
> > "Schimpe, Christina" <christina.schimpe@intel.com> writes:
> >
> >>>>>> +
> >>>>>> +    # At this point we have a couple of core files, the gcore
> >>>>>> + one generated by
> >>>>>> +    # GDB and the one generated by the operating system.  Make
> >>>>>> + sure GDB can
> >>>>>> +    # read both correctly.
> >>>>>> +
> >>>>>> +    if {$gcore_generated} {
> >>>>>> +	clean_restart $binfile
> >>>>>> +
> >>>>>> +	with_test_prefix "gcore corefile" {
> >>>>>> +	    check_core_file $gcore_filename $ssp_in_gcore
> >>>>>> +	}
> >>>>>> +    } else {
> >>>>>> +	fail "gcore corefile not generated"
> >>>>>
> >>>>> It's better, where possible, to avoid having pass/fail results
> >>>>> that only show up down some code paths.
> >>>>>
> >>>>> In this case it's easy to avoid having a stray 'fail' by
> >>>>> restructuring the code too:
> >>>>>
> >>>>>    gdb_assert { $gcore_generated } "gcore corefile created"
> >>>>>    if { $gcore_generated } {
> >>>>>      ... etc ...
> >>>>>    }
> >>>>>
> >>>>> Now you'll always have either a pass or fail based on the gcore
> >>>>> being generated.
> >>>>
> >>>> Good idea. I did that for aarch64-gcs-core.exp.
> >>
> >> If no OS corefile is found we will see a FAIL here.
> >> The usual coredump testing doesn't fail in case the coredump file is not
> found.
> >> So all gdb.base/corefile*.exp tests have sth. like:
> >>
> >> set corefile [core_find $binfile {}]
> >> if {$corefile == ""} {
> >>      return
> >> }
> >>
> >> This can happen in case corefiles are managed, for instance, by apport on
> ubuntu.
> >> Do we want a different behaviour ?
> >
> > Interesting point. Perhaps a FAIL Isn't the best result to report in
> > this case, but IMHO it would be worth reporting an UNTESTED or perhaps
> > UNSUPPORTED result rather than silently returning.
> >
> > I don't have a strong opinion on this matter though.
> >
> 
> When testing core files, I usually change the core_pattern in
> /proc/sys/kernel/core_pattern so the files are properly generated and saved.
> Personally I find it useful to have a FAIL output when the core file generation
> didn't work.

Thank you for the feedback.

I also use /proc/sys/kernel/core_pattern to fix core file testing on my machine. However, by default
corefiles do not work in our testsuite for the recent OS I have been testing (ubuntu 24, fedora 42).

I created this RFC patch to clarify if we should use UNTESTED or FAIL:
https://sourceware.org/pipermail/gdb-patches/2025-August/219880.html

I know it's not the most important topic, but it would be nice if we could agree on a commonly accepted
solution.

Christina
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Sean Fennelly, Jeffrey Schneiderman, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928


  reply	other threads:[~2025-08-11 11:53 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-28  8:27 [PATCH v5 00/12] Add CET shadow stack support Christina Schimpe
2025-06-28  8:27 ` [PATCH v5 01/12] gdb, testsuite: Extend core_find procedure to save program output Christina Schimpe
2025-07-14 12:21   ` Andrew Burgess
2025-07-17 13:37     ` Schimpe, Christina
2025-06-28  8:28 ` [PATCH v5 02/12] gdbserver: Add optional runtime register set type Christina Schimpe
2025-06-28  8:28 ` [PATCH v5 03/12] gdbserver: Add assert in x86_linux_read_description Christina Schimpe
2025-06-28  8:28 ` [PATCH v5 04/12] gdb: Sync up x86-gcc-cpuid.h with cpuid.h from gcc 14 branch Christina Schimpe
2025-06-28  8:28 ` [PATCH v5 05/12] gdb, gdbserver: Use xstate_bv for target description creation on x86 Christina Schimpe
2025-07-14 13:52   ` Andrew Burgess
2025-07-15 10:28     ` Schimpe, Christina
2025-07-23 12:47       ` Schimpe, Christina
2025-08-05 13:47         ` Andrew Burgess
2025-06-28  8:28 ` [PATCH v5 06/12] gdb, gdbserver: Add support of Intel shadow stack pointer register Christina Schimpe
2025-07-25 12:49   ` Andrew Burgess
2025-07-25 15:03     ` Schimpe, Christina
2025-08-01 12:54       ` Schimpe, Christina
2025-08-05 13:57       ` Andrew Burgess
2025-08-06 19:53         ` Schimpe, Christina
2025-08-06 19:54           ` Schimpe, Christina
2025-08-07  3:17             ` Thiago Jung Bauermann
2025-08-14 11:39           ` Andrew Burgess
2025-07-29 13:51   ` Andrew Burgess
2025-08-01 12:40     ` Schimpe, Christina
2025-08-10 19:01   ` H.J. Lu
2025-08-10 20:07     ` Schimpe, Christina
2025-06-28  8:28 ` [PATCH v5 07/12] gdb: amd64 linux coredump support with shadow stack Christina Schimpe
2025-07-29 14:46   ` Andrew Burgess
2025-07-30  1:55     ` Thiago Jung Bauermann
2025-07-30 11:42       ` Schimpe, Christina
2025-08-04 15:28         ` Schimpe, Christina
2025-08-05  4:29           ` Thiago Jung Bauermann
2025-08-05 15:29             ` Schimpe, Christina
2025-08-06 20:52             ` Luis
2025-08-11 11:52               ` Schimpe, Christina [this message]
2025-08-04 12:45     ` Schimpe, Christina
2025-06-28  8:28 ` [PATCH v5 08/12] gdb: Handle shadow stack pointer register unwinding for amd64 linux Christina Schimpe
2025-07-30  9:58   ` Andrew Burgess
2025-07-30 12:06     ` Schimpe, Christina
2025-06-28  8:28 ` [PATCH v5 09/12] gdb, gdbarch: Enable inferior calls for shadow stack support Christina Schimpe
2025-07-30 10:42   ` Andrew Burgess
2025-06-28  8:28 ` [PATCH v5 10/12] gdb: Implement amd64 linux shadow stack support for inferior calls Christina Schimpe
2025-07-30 11:58   ` Andrew Burgess
2025-07-31 12:32     ` Schimpe, Christina
2025-06-28  8:28 ` [PATCH v5 11/12] gdb, gdbarch: Introduce gdbarch method to get the shadow stack pointer Christina Schimpe
2025-07-30 12:22   ` Andrew Burgess
2025-08-04 13:01     ` Schimpe, Christina
2025-08-14 15:50       ` Andrew Burgess
2025-08-19 15:37         ` Schimpe, Christina
2025-06-28  8:28 ` [PATCH v5 12/12] gdb: Enable displaced stepping with shadow stack on amd64 linux Christina Schimpe
2025-07-30 13:59   ` Andrew Burgess
2025-07-31 17:29     ` Schimpe, Christina
2025-07-08 15:18 ` [PATCH v5 00/12] Add CET shadow stack support Schimpe, Christina
2025-08-14  7:52   ` Schimpe, Christina
2025-07-11 10:36 ` Luis Machado
2025-07-11 13:54   ` Schimpe, Christina
2025-07-11 15:54     ` Luis Machado
2025-07-13 14:01       ` Schimpe, Christina
2025-07-13 19:05         ` Luis Machado
2025-07-13 19:57           ` Schimpe, Christina
2025-07-14  7:13           ` Luis Machado
2025-07-17 12:01             ` Schimpe, Christina
2025-07-17 14:59               ` Luis Machado
2025-07-23 12:45                 ` Schimpe, Christina
2025-07-28 17:05                   ` Luis Machado
2025-07-28 17:20                     ` Schimpe, Christina
2025-08-20  9:16 ` Schimpe, Christina
2025-08-20 15:21   ` 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=SN7PR11MB7638ED439EF2451568A19056F928A@SN7PR11MB7638.namprd11.prod.outlook.com \
    --to=christina.schimpe@intel.com \
    --cc=aburgess@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=luis.machado.foss@gmail.com \
    --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