RE: [PATCH v5 07/12] gdb: amd64 linux coredump support with shadow stack.

Schimpe, Christina
2025-08-11T11:53:24Z

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