[2/3] gdb/testsuite: add test for core file with a 0 pid

  This patch contains a test for this commit:

  commit c820c52a914cc9d7c63cb41ad396f4ddffff2196
  Date:   Fri Aug 6 19:45:58 2010 +0000

              * thread.c (add_thread_silent): Use null_ptid instead of
              minus_one_ptid while getting rid of stale inferior_ptid.

This is another test that has been carried in the Fedora GDB tree for
some time, and I thought that it would be worth merging to master.  I
don't believe there is any test like this currently in the testsuite.

The original issue was reported in this thread:

  https://inbox.sourceware.org/gdb-patches/AANLkTi=zuEDw6qiZ1jRatkdwHO99xF2Qu+WZ7i0EQjef@mail.gmail.com/

The problem was that when GDB was used to open a vmcore (core file)
image generated by the Linux kernel GDB would (sometimes) crash with
an assertion failure:

  thread.c:884: internal-error: switch_to_thread: Assertion `inf != NULL' failed.

To understand what's going on we need some background; a vmcore file
represents each processor core in the same way that a standard
application core file represents threads.  Thus, we might say, a
vmcore file represents cores as threads.

When writing a vmcore file, the kernel will store the pid of the
process currently running on that core as the thread's lwpid.

However, if a core is idle, with no process currently running on it,
then the lwpid for that thread is stored as 0 in the vmcore file.  If
multiple cores are idle then multiple threads will have a lwpid of 0.

Back in 2010, the original issue reported tried to change the kernel's
behaviour in this thread:

  https://lkml.org/lkml/2010/8/3/75

This change was rejected by the kernel team, the current
behaviour (lwpid of 0) was considered correct.  I've checked the
source of a recent kernel.  The code mentioned in the lkml.org posting
has moved, it's now in the function crash_save_cpu in the file
kernel/kexec_core.c, but the general behaviour is unchanged, an idle
core will have an lwpid of 0, so I think GDB still needs to be able to
handle this case.

When GDB loads a vmcore file (which is handled just like any other
core file) the sections are processed in core_open to generate the
threads for the core file.  The processing is done by calling
add_to_thread_list, a function which looks for sections named .reg/NN
where NN is the lwpid of the thread, GDB then builds a ptid_t for the
new thread and calls add_thread.

Remember, in our case the lwpid is 0.  Now for the first thread this
is fine, if a little weird, 0 isn't usually a valid lwpid, but that's
OK, GDB creates a thread with lwpid of 0 and carries on.

When we find the next thread (core) with lwpid of 0, we attempt to
create another thread with an lwpid of 0.  This of course clashes with
the previously created thread, they have the same ptid_t, so GDB tries
to delete the first thread.

And it was within this thread delete code that we triggered a bug
which would then cause GDB to assert -- when deleting we tried to
switch to a thread with minus_one_ptid, this resulted in a call to
find_inferior_pid (passing in minus_one_ptid's pid, which is -1), the
find_inferior_pid call fails and returns NULL, which then triggered an
assert in switch_to_thread.

The actual details of the why the assert triggered are really not
important.  What's important (I think) is that a vmcore file might
have this interesting lwpid of 0 characteristic, which isn't something
we see in "normal" application core files, and it is this that I think
we should be testing.

Now, you might be thinking: isn't deleting the first thread the wrong
thing to do?  If the vmcore file has two threads that represent two
cores, and both have an lwpid of 0 (indicating both cores are idle),
then surely GDB should still represent this as two threads?  You're
not wrong.  This was mentioned by Pedro in the original GDB mailing
list thread here:

  https://inbox.sourceware.org/gdb-patches/201008061057.03037.pedro@codesourcery.com/

This is indeed a problem, and this problem is still present in GDB
today.  I plan to try and address this in a later commit, however,
this first commit is about getting a test in place to confirm that GDB
at a minimum doesn't crash when loading such a vmcore file.

And so, finally, what's in this commit?

This commit contains a new test.  The test doesn't actually contain a
vmcore file.  Instead I've created a standard application core file
that contains two threads, and then manually edited the core file to
set the lwpid of each thread to 0.

To further reduce the size of the core file (as it will be stored in
git), I've zeroed all of the LOAD-able segments in the core file.
This test really doesn't care about that part of the core file, we
only really care about loading the register's, this is enough to
confirm that the GDB doesn't crash.

Obviously as the core file is pre-generated, this test is architecture
specific.  There are already a few tests in gdb.arch/ that include
pre-generate core files.  Just as those existing tests do, I've
compressed the core file with bzip2, which reduces it to just 750
bytes.  I have structured the test so that if/when this patch is
merged I can add some additional core files for other architectures,
however, these are not included in this commit.

The test simply expands the core file, and then loads it into GDB.
One interesting thing to note is that GDB reports the core file
loading like this:

  (gdb) core-file ./gdb/testsuite/outputs/gdb.arch/core-file-pid0/core-file-pid0.x86-64.core
  [New process 1]
  [New process 1]
  Failed to read a valid object file image from memory.
  Core was generated by `./segv-mt'.
  Program terminated with signal SIGSEGV, Segmentation fault.
  The current thread has terminated
  (gdb)

There's two interesting things here: first, the repeated "New process
1" message.  This is caused because linux_core_pid_to_str reports
anything with an lwpid of 0 as a process, rather than an LWP.  And
second, the "The current thread has terminated" message.  This is
because the first thread in the core file is the current thread, but
when GDB loads the second thread (which also has lwpid 0) this causes
the first thread to be deleted, as a result GDB thinks that the
current (first) thread has terminated.

As I said previously, both of these problems are a result of the lwpid
0 aliasing, which is not being fixed in this commit -- this commit is
just confirming that GDB doesn't crash when loading this core file.
---
 gdb/testsuite/gdb.arch/core-file-pid0.exp     |  63 ++++++++++++++++++
 .../gdb.arch/core-file-pid0.x86-64.core.bz2   | Bin 0 -> 750 bytes
 2 files changed, 63 insertions(+)
 create mode 100644 gdb/testsuite/gdb.arch/core-file-pid0.exp
 create mode 100644 gdb/testsuite/gdb.arch/core-file-pid0.x86-64.core.bz2
  

On Mon,  5 Jun 2023 10:11:08 +0100
Andrew Burgess via Gdb-patches <gdb-patches@sourceware.org> wrote:

> This patch contains a test for this commit:
> 
>   commit c820c52a914cc9d7c63cb41ad396f4ddffff2196
>   Date:   Fri Aug 6 19:45:58 2010 +0000
> 
>               * thread.c (add_thread_silent): Use null_ptid instead of
>               minus_one_ptid while getting rid of stale inferior_ptid.
> 
> This is another test that has been carried in the Fedora GDB tree for
> some time, and I thought that it would be worth merging to master.  I
> don't believe there is any test like this currently in the testsuite.
> 
> The original issue was reported in this thread:
> 
>   https://inbox.sourceware.org/gdb-patches/AANLkTi=zuEDw6qiZ1jRatkdwHO99xF2Qu+WZ7i0EQjef@mail.gmail.com/
> 
> The problem was that when GDB was used to open a vmcore (core file)
> image generated by the Linux kernel GDB would (sometimes) crash with
> an assertion failure:
> 
>   thread.c:884: internal-error: switch_to_thread: Assertion `inf != NULL' failed.
> 
> To understand what's going on we need some background; a vmcore file
> represents each processor core in the same way that a standard
> application core file represents threads.  Thus, we might say, a
> vmcore file represents cores as threads.
> 
> When writing a vmcore file, the kernel will store the pid of the
> process currently running on that core as the thread's lwpid.
> 
> However, if a core is idle, with no process currently running on it,
> then the lwpid for that thread is stored as 0 in the vmcore file.  If
> multiple cores are idle then multiple threads will have a lwpid of 0.
> 
> Back in 2010, the original issue reported tried to change the kernel's
> behaviour in this thread:
> 
>   https://lkml.org/lkml/2010/8/3/75
> 
> This change was rejected by the kernel team, the current
> behaviour (lwpid of 0) was considered correct.  I've checked the
> source of a recent kernel.  The code mentioned in the lkml.org posting
> has moved, it's now in the function crash_save_cpu in the file
> kernel/kexec_core.c, but the general behaviour is unchanged, an idle
> core will have an lwpid of 0, so I think GDB still needs to be able to
> handle this case.
> 
> When GDB loads a vmcore file (which is handled just like any other
> core file) the sections are processed in core_open to generate the
> threads for the core file.  The processing is done by calling
> add_to_thread_list, a function which looks for sections named .reg/NN
> where NN is the lwpid of the thread, GDB then builds a ptid_t for the
> new thread and calls add_thread.
> 
> Remember, in our case the lwpid is 0.  Now for the first thread this
> is fine, if a little weird, 0 isn't usually a valid lwpid, but that's
> OK, GDB creates a thread with lwpid of 0 and carries on.
> 
> When we find the next thread (core) with lwpid of 0, we attempt to
> create another thread with an lwpid of 0.  This of course clashes with
> the previously created thread, they have the same ptid_t, so GDB tries
> to delete the first thread.
> 
> And it was within this thread delete code that we triggered a bug
> which would then cause GDB to assert -- when deleting we tried to
> switch to a thread with minus_one_ptid, this resulted in a call to
> find_inferior_pid (passing in minus_one_ptid's pid, which is -1), the
> find_inferior_pid call fails and returns NULL, which then triggered an
> assert in switch_to_thread.
> 
> The actual details of the why the assert triggered are really not
> important.  What's important (I think) is that a vmcore file might
> have this interesting lwpid of 0 characteristic, which isn't something
> we see in "normal" application core files, and it is this that I think
> we should be testing.
> 
> Now, you might be thinking: isn't deleting the first thread the wrong
> thing to do?  If the vmcore file has two threads that represent two
> cores, and both have an lwpid of 0 (indicating both cores are idle),
> then surely GDB should still represent this as two threads?  You're
> not wrong.  This was mentioned by Pedro in the original GDB mailing
> list thread here:
> 
>   https://inbox.sourceware.org/gdb-patches/201008061057.03037.pedro@codesourcery.com/
> 
> This is indeed a problem, and this problem is still present in GDB
> today.  I plan to try and address this in a later commit, however,
> this first commit is about getting a test in place to confirm that GDB
> at a minimum doesn't crash when loading such a vmcore file.
> 
> And so, finally, what's in this commit?
> 
> This commit contains a new test.  The test doesn't actually contain a
> vmcore file.  Instead I've created a standard application core file
> that contains two threads, and then manually edited the core file to
> set the lwpid of each thread to 0.
> 
> To further reduce the size of the core file (as it will be stored in
> git), I've zeroed all of the LOAD-able segments in the core file.
> This test really doesn't care about that part of the core file, we
> only really care about loading the register's, this is enough to
> confirm that the GDB doesn't crash.
> 
> Obviously as the core file is pre-generated, this test is architecture
> specific.  There are already a few tests in gdb.arch/ that include
> pre-generate core files.  Just as those existing tests do, I've
> compressed the core file with bzip2, which reduces it to just 750
> bytes.  I have structured the test so that if/when this patch is
> merged I can add some additional core files for other architectures,
> however, these are not included in this commit.
> 
> The test simply expands the core file, and then loads it into GDB.
> One interesting thing to note is that GDB reports the core file
> loading like this:
> 
>   (gdb) core-file ./gdb/testsuite/outputs/gdb.arch/core-file-pid0/core-file-pid0.x86-64.core
>   [New process 1]
>   [New process 1]
>   Failed to read a valid object file image from memory.
>   Core was generated by `./segv-mt'.
>   Program terminated with signal SIGSEGV, Segmentation fault.
>   The current thread has terminated
>   (gdb)
> 
> There's two interesting things here: first, the repeated "New process
> 1" message.  This is caused because linux_core_pid_to_str reports
> anything with an lwpid of 0 as a process, rather than an LWP.  And
> second, the "The current thread has terminated" message.  This is
> because the first thread in the core file is the current thread, but
> when GDB loads the second thread (which also has lwpid 0) this causes
> the first thread to be deleted, as a result GDB thinks that the
> current (first) thread has terminated.
> 
> As I said previously, both of these problems are a result of the lwpid
> 0 aliasing, which is not being fixed in this commit -- this commit is
> just confirming that GDB doesn't crash when loading this core file.

Great explanation! :)

Approved-by: Kevin Buettner <kevinb@redhat.com>
  

Hi Andrew,

I'm skimming the thread to catch up, and noticed this:

On 2023-06-05 10:11, Andrew Burgess via Gdb-patches wrote:
> +++ b/gdb/testsuite/gdb.arch/core-file-pid0.exp
> @@ -0,0 +1,63 @@
> +# This testcase is part of GDB, the GNU debugger.
> +#
> +# Copyright 2023 Free Software Foundation, Inc.
> +#
> +# 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 2 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, write to the Free Software
> +# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
> +

Wrong license (GPLv2), and wrong header -- we haven't been using the snail
mail FSF header in years.
  

Pedro Alves <pedro@palves.net> writes:

> Hi Andrew,
>
> I'm skimming the thread to catch up, and noticed this:
>
> On 2023-06-05 10:11, Andrew Burgess via Gdb-patches wrote:
>> +++ b/gdb/testsuite/gdb.arch/core-file-pid0.exp
>> @@ -0,0 +1,63 @@
>> +# This testcase is part of GDB, the GNU debugger.
>> +#
>> +# Copyright 2023 Free Software Foundation, Inc.
>> +#
>> +# 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 2 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, write to the Free Software
>> +# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
>> +
>
> Wrong license (GPLv2), and wrong header -- we haven't been using the snail
> mail FSF header in years.

Ooops.  Thanks for spotting this.

I pushed the patch below to correct this mistake.

Thanks,
Andrew

---

commit 7c632c2a696fb68e5575db1e2c934788a831e578
Author: Andrew Burgess <aburgess@redhat.com>
Date:   Fri Jul 7 10:51:53 2023 +0100

    gdb/testsuite: fix license on recently added file
    
    The license header on a file I recently contributed was incorrect.
    The file was added in commit:
    
      commit 087969169836f802a09b1cd0502d2f22d7a8f7dc
      Date:   Tue May 23 11:25:21 2023 +0100
    
          gdb: handle core files with .reg/0 section names
    
    The problems were:
    
      - GPLv2 instead of GPLv3,
      - Use the FSF postal address rather than their URL.
    
    Nobody else has touched the file since I merged it, so I don't believe
    there are any problems with me changing the license, this commit does
    just that.

diff --git a/gdb/testsuite/gdb.arch/core-file-pid0.exp b/gdb/testsuite/gdb.arch/core-file-pid0.exp
index 6e91111b44b..56746cca567 100644
--- a/gdb/testsuite/gdb.arch/core-file-pid0.exp
+++ b/gdb/testsuite/gdb.arch/core-file-pid0.exp
@@ -4,7 +4,7 @@
 #
 # 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 2 of the License, or
+# 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,
@@ -13,8 +13,7 @@
 # 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, write to the Free Software
-# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
 
 # Some kernel core files have PID 0 (for the idle task), check that
 # GDB can handle such a core file.
  

Andrew Burgess <aburgess@redhat.com> writes:

> This patch contains a test for this commit:
>
>   commit c820c52a914cc9d7c63cb41ad396f4ddffff2196
>   Date:   Fri Aug 6 19:45:58 2010 +0000
>
>               * thread.c (add_thread_silent): Use null_ptid instead of
>               minus_one_ptid while getting rid of stale inferior_ptid.
>
> This is another test that has been carried in the Fedora GDB tree for
> some time, and I thought that it would be worth merging to master.  I
> don't believe there is any test like this currently in the testsuite.
>
> The original issue was reported in this thread:
>
>   https://inbox.sourceware.org/gdb-patches/AANLkTi=zuEDw6qiZ1jRatkdwHO99xF2Qu+WZ7i0EQjef@mail.gmail.com/
>
> The problem was that when GDB was used to open a vmcore (core file)
> image generated by the Linux kernel GDB would (sometimes) crash with
> an assertion failure:
>
>   thread.c:884: internal-error: switch_to_thread: Assertion `inf != NULL' failed.
>
> To understand what's going on we need some background; a vmcore file
> represents each processor core in the same way that a standard
> application core file represents threads.  Thus, we might say, a
> vmcore file represents cores as threads.
>
> When writing a vmcore file, the kernel will store the pid of the
> process currently running on that core as the thread's lwpid.
>
> However, if a core is idle, with no process currently running on it,
> then the lwpid for that thread is stored as 0 in the vmcore file.  If
> multiple cores are idle then multiple threads will have a lwpid of 0.
>
> Back in 2010, the original issue reported tried to change the kernel's
> behaviour in this thread:
>
>   https://lkml.org/lkml/2010/8/3/75
>
> This change was rejected by the kernel team, the current
> behaviour (lwpid of 0) was considered correct.  I've checked the
> source of a recent kernel.  The code mentioned in the lkml.org posting
> has moved, it's now in the function crash_save_cpu in the file
> kernel/kexec_core.c, but the general behaviour is unchanged, an idle
> core will have an lwpid of 0, so I think GDB still needs to be able to
> handle this case.
>
> When GDB loads a vmcore file (which is handled just like any other
> core file) the sections are processed in core_open to generate the
> threads for the core file.  The processing is done by calling
> add_to_thread_list, a function which looks for sections named .reg/NN
> where NN is the lwpid of the thread, GDB then builds a ptid_t for the
> new thread and calls add_thread.
>
> Remember, in our case the lwpid is 0.  Now for the first thread this
> is fine, if a little weird, 0 isn't usually a valid lwpid, but that's
> OK, GDB creates a thread with lwpid of 0 and carries on.
>
> When we find the next thread (core) with lwpid of 0, we attempt to
> create another thread with an lwpid of 0.  This of course clashes with
> the previously created thread, they have the same ptid_t, so GDB tries
> to delete the first thread.
>
> And it was within this thread delete code that we triggered a bug
> which would then cause GDB to assert -- when deleting we tried to
> switch to a thread with minus_one_ptid, this resulted in a call to
> find_inferior_pid (passing in minus_one_ptid's pid, which is -1), the
> find_inferior_pid call fails and returns NULL, which then triggered an
> assert in switch_to_thread.
>
> The actual details of the why the assert triggered are really not
> important.  What's important (I think) is that a vmcore file might
> have this interesting lwpid of 0 characteristic, which isn't something
> we see in "normal" application core files, and it is this that I think
> we should be testing.
>
> Now, you might be thinking: isn't deleting the first thread the wrong
> thing to do?  If the vmcore file has two threads that represent two
> cores, and both have an lwpid of 0 (indicating both cores are idle),
> then surely GDB should still represent this as two threads?  You're
> not wrong.  This was mentioned by Pedro in the original GDB mailing
> list thread here:
>
>   https://inbox.sourceware.org/gdb-patches/201008061057.03037.pedro@codesourcery.com/
>
> This is indeed a problem, and this problem is still present in GDB
> today.  I plan to try and address this in a later commit, however,
> this first commit is about getting a test in place to confirm that GDB
> at a minimum doesn't crash when loading such a vmcore file.
>
> And so, finally, what's in this commit?
>
> This commit contains a new test.  The test doesn't actually contain a
> vmcore file.  Instead I've created a standard application core file
> that contains two threads, and then manually edited the core file to
> set the lwpid of each thread to 0.
>
> To further reduce the size of the core file (as it will be stored in
> git), I've zeroed all of the LOAD-able segments in the core file.
> This test really doesn't care about that part of the core file, we
> only really care about loading the register's, this is enough to
> confirm that the GDB doesn't crash.
>
> Obviously as the core file is pre-generated, this test is architecture
> specific.  There are already a few tests in gdb.arch/ that include
> pre-generate core files.  Just as those existing tests do, I've
> compressed the core file with bzip2, which reduces it to just 750
> bytes.  I have structured the test so that if/when this patch is
> merged I can add some additional core files for other architectures,
> however, these are not included in this commit.
>
> The test simply expands the core file, and then loads it into GDB.
> One interesting thing to note is that GDB reports the core file
> loading like this:
>
>   (gdb) core-file ./gdb/testsuite/outputs/gdb.arch/core-file-pid0/core-file-pid0.x86-64.core
>   [New process 1]
>   [New process 1]
>   Failed to read a valid object file image from memory.
>   Core was generated by `./segv-mt'.
>   Program terminated with signal SIGSEGV, Segmentation fault.
>   The current thread has terminated
>   (gdb)
>
> There's two interesting things here: first, the repeated "New process
> 1" message.  This is caused because linux_core_pid_to_str reports
> anything with an lwpid of 0 as a process, rather than an LWP.  And
> second, the "The current thread has terminated" message.  This is
> because the first thread in the core file is the current thread, but
> when GDB loads the second thread (which also has lwpid 0) this causes
> the first thread to be deleted, as a result GDB thinks that the
> current (first) thread has terminated.
>
> As I said previously, both of these problems are a result of the lwpid
> 0 aliasing, which is not being fixed in this commit -- this commit is
> just confirming that GDB doesn't crash when loading this core file.
> ---
>  gdb/testsuite/gdb.arch/core-file-pid0.exp     |  63 ++++++++++++++++++
>  .../gdb.arch/core-file-pid0.x86-64.core.bz2   | Bin 0 -> 750 bytes
>  2 files changed, 63 insertions(+)
>  create mode 100644 gdb/testsuite/gdb.arch/core-file-pid0.exp
>  create mode 100644 gdb/testsuite/gdb.arch/core-file-pid0.x86-64.core.bz2
>
> diff --git a/gdb/testsuite/gdb.arch/core-file-pid0.exp b/gdb/testsuite/gdb.arch/core-file-pid0.exp
> new file mode 100644
> index 00000000000..b960dfe095b
> --- /dev/null
> +++ b/gdb/testsuite/gdb.arch/core-file-pid0.exp
> @@ -0,0 +1,63 @@
> +# This testcase is part of GDB, the GNU debugger.
> +#
> +# Copyright 2023 Free Software Foundation, Inc.
> +#
> +# 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 2 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, write to the Free Software
> +# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
> +
> +# Some kernel core files have PID 0 (for the idle task), check that
> +# GDB can handle such a core file.
> +
> +standard_testfile
> +
> +# Set CF_NAME, the name of the compressed core file within the source
> +# tree, and CF_SIZE, the size (in bytes) of the uncompressed core
> +# file.
> +if {[istarget "x86_64-*-linux*"]} {
> +    set cf_name ${testfile}.x86-64.core.bz2
> +    set cf_size 8757248
> +} else {
> +    unsupported "no pre-generated core file for this target"
> +}

It was pointed out to me that after reporting 'unsupported', there
should be a return.  Without the return we end up seeing TCL errors
because the cf_name variable is not defined.

Fixed with the patch below, which I have gone ahead and pushed.

Thanks,
Andrew

---

commit 44c8334f4af5b9895d196077f23e20e15eff4c03
Author: Andrew Burgess <aburgess@redhat.com>
Date:   Mon Jul 10 12:05:21 2023 +0100

    gdb/testsuite: return after reporting a test unsupported
    
    In this commit:
    
      commit 8bcead69665af3a9f9867cd34c3a1daf22120027
      Date:   Tue May 23 11:25:01 2023 +0100
    
          gdb/testsuite: add test for core file with a 0 pid
    
    a new test gdb.arch/core-file-pid0.exp was added.  This test includes
    a pre-generated core file for x86-64 and for other architectures the
    test reports 'unsupported'.
    
    However, after reporting 'unsupported' the test failed to perform an
    early return, so the test would then carry on and try to actually
    perform the test, which resulted in some TCL errors.
    
    Fix this by returning after reporting the test unsupported.

diff --git a/gdb/testsuite/gdb.arch/core-file-pid0.exp b/gdb/testsuite/gdb.arch/core-file-pid0.exp
index 56746cca567..46b8c6db5ed 100644
--- a/gdb/testsuite/gdb.arch/core-file-pid0.exp
+++ b/gdb/testsuite/gdb.arch/core-file-pid0.exp
@@ -28,6 +28,7 @@ if {[istarget "x86_64-*-linux*"]} {
     set cf_size 8757248
 } else {
     unsupported "no pre-generated core file for this target"
+    return -1
 }
 
 # Decompress the core file.