From: Luis <luis.machado.foss@gmail.com>
To: Thiago Jung Bauermann <thiago.bauermann@linaro.org>,
"Schimpe, Christina" <christina.schimpe@intel.com>
Cc: Andrew Burgess <aburgess@redhat.com>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
"luis.machado@arm.com" <luis.machado@arm.com>
Subject: Re: [PATCH v5 07/12] gdb: amd64 linux coredump support with shadow stack.
Date: Wed, 6 Aug 2025 21:52:12 +0100 [thread overview]
Message-ID: <40bebcad-2fcf-4340-82bb-2694be2af12c@gmail.com> (raw)
In-Reply-To: <87cy9ajsr5.fsf@linaro.org>
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.
next prev parent reply other threads:[~2025-08-06 20: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 [this message]
2025-08-11 11:52 ` Schimpe, Christina
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=40bebcad-2fcf-4340-82bb-2694be2af12c@gmail.com \
--to=luis.machado.foss@gmail.com \
--cc=aburgess@redhat.com \
--cc=christina.schimpe@intel.com \
--cc=gdb-patches@sourceware.org \
--cc=luis.machado@arm.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