time to workaround libc/13097 in fsf gdb?

  On 09/19/2014 03:38 PM, Pedro Alves wrote:
> OK, I've investigated this further.  I think that we're a couple steps
> away from being able to list the vdso without causing other issues.
> I'll reply again with a patch based on your "new" patch, but that matches
> the vdso by address independently of add-symbol-file-from-memory.

Here it is.  WDYT?

-------------
[PATCH] Subject: Work around PR libc/13097 "linux-vdso.so.1"

With upstream glibc, GDB prints:

	warning: Could not load shared library symbols for linux-vdso.so.1.
	Do you need "set solib-search-path" or "set sysroot"?

A bug's been filed for glibc a few years back:

  http://sourceware.org/bugzilla/show_bug.cgi?id=13097

but it's still not resolved.  It's not clear whether there's even
consensus that this is indeed a glibc bug.  It would actually be nice
if GDB also listed the vdso in the shared library list, but there are
some design considerations with that:

 - the vDSO is mapped by the kernel, not userspace, therefore we
   should load its symbols right from the process's start of life,
   even before glibc / the userspace loader sets up the initial DSO
   list.  The program might even be using a custom loader or no
   loader.

 - that kind of hints at that solib.c should handle retrieving shared
   library lists from more than one source, and that symfile-mem.c's
   loading of the vdso would be converted to load and relocate the
   vdso's bfd behind the target_so_ops interface.

 - and then, once glibc links in the vdso to its DSO list, we'd need
   to either:

    a) somehow hand over the vdso from one target_so_ops to the
      other
    b) or simply keep hiding glibc's entry.

And then b) seems the simplest.

With that in mind, this patch simply discards the vDSO from glibc's
reported shared library list.

We can match the vdso address found through AT_SYSINFO_EHDR with the
addresses found iterating the dynamic linker list, to know which
dynamic linker entry is the vdso.

Note that symfile-mem.c is not present in every configuration that
uses solib-svr4.c.  It actually probably should always be linked in
GDB (added to COMMON_OBS), so that the "add-symbol-file-from-memory"
command is always available for all targets.  But even if we did that,
even though harmless, it's unnecessary or a bit wrong in principle
even, to try the target_auxv_search lookup against all targets (even
though harmless; at least currently).

So solve that, this moves the target_auxv_search lookup to a gdbarch
hook, registered for all Linux architectures, and then both
solib-svr4.c and symfile-mem.c can both use it.

Tested on x86_64 Fedora 20.

gdb/
2014-09-19  Jan Kratochvil  <jan.kratochvil@redhat.com>
	    Pedro Alves  <palves@redhat.com>

	PR 14466
	* arch-utils.c (default_vsyscall_address): New function.
	* arch-utils.h (default_vsyscall_address): New declaration.
	* gdbarch.sh (vsyscall_address): New hook.
	* gdbarch.h, gdbarch.c: Regenerate.
	* linux-tdep.c (linux_vsyscall_address): New function.
	(linux_init_abi): Install linux_vsyscall_address as
	vsyscall_address gdbarch hook.
	* solib-svr4.c (svr4_read_so_list): Rename to ...
	(svr4_current_sos_1): ... this and change the function comment.
	(svr4_current_sos): New function.
	* symfile-mem.c (add_vsyscall_page): Use gdbarch_vsyscall_address.

gdb/testsuite/
2014-09-19  Jan Kratochvil  <jan.kratochvil@redhat.com>
	    Pedro Alves  <palves@redhat.com>

	PR 14466
	* gdb.base/vdso-warning.c: New file.
	* gdb.base/vdso-warning.exp: New file.
---
 gdb/arch-utils.c                        |  8 +++++
 gdb/arch-utils.h                        |  4 +++
 gdb/gdbarch.c                           | 23 ++++++++++++++
 gdb/gdbarch.h                           |  4 +++
 gdb/gdbarch.sh                          |  3 ++
 gdb/linux-tdep.c                        | 13 ++++++++
 gdb/solib-svr4.c                        | 41 +++++++++++++++++++++++--
 gdb/symfile-mem.c                       |  5 ++-
 gdb/testsuite/gdb.base/vdso-warning.c   | 22 ++++++++++++++
 gdb/testsuite/gdb.base/vdso-warning.exp | 54 +++++++++++++++++++++++++++++++++
 10 files changed, 172 insertions(+), 5 deletions(-)
 create mode 100644 gdb/testsuite/gdb.base/vdso-warning.c
 create mode 100644 gdb/testsuite/gdb.base/vdso-warning.exp
  

On Fri, 19 Sep 2014 16:41:34 +0200, Pedro Alves wrote:
> Here it is.  WDYT?
[...]
> --- a/gdb/solib-svr4.c
> +++ b/gdb/solib-svr4.c
[...]
> @@ -1478,6 +1479,42 @@ svr4_current_sos (void)
>    return svr4_current_sos_direct (info);
>  }
> 
> +/* Implement the "current_sos" target_so_ops method.  */
> +
> +static struct so_list *
> +svr4_current_sos (void)
> +{
> +  struct so_list *so_head = svr4_current_sos_1 ();
> +  struct objfile *objfile;
> +  struct obj_section *osect;
> +  CORE_ADDR vsyscall_addr = gdbarch_vsyscall_address (target_gdbarch ());
> +
> +  /* Filter out the vDSO module, if present.  Its symbol file would
> +     not be found on disk.  The vDSO/vsyscall's OBJFILE is instead
> +     managed by symfile-mem.c:add_vsyscall_page.  */
> +  if (vsyscall_addr != 0)
> +    {
> +      struct so_list **sop;
> +
> +      sop = &so_head;
> +      while (*sop != NULL)
> +	{
> +	  struct so_list *so = *sop;
> +
> +	  if (so->lm_info->l_addr_inferior == vsyscall_addr)

This won't work as l_addr_inferior (and also l_addr) do not necessarily
represent the real starting address of the ELF if the ELF itself is
"prelinked".  For some reason vDSOs on some kernels look like prelinked.

kernel-3.16.2-200.fc20.x86_64 appears sane, vDSO is 0-based.

But for example kernel-2.6.32-220.el6.x86_64 is "prelinked", see below.


That's the pain of solib-svr4.c which is OS-agnostic and so it cannot find out
start of the ELF file just from link map.  gdbserver can find it as it can
depend on /proc/PID/{s,}maps as its linux-low.c is Linux-specific.
That was implemented in unfinished/pending:
	[PATCH v5 0/8] Validate binary before use
	Message-ID: <20140319223004.14668.20989.stgit@host1.jankratochvil.net>


Thanks,
Jan


kernel-2.6.32-220.el6.x86_64
(gdb) p *_r_debug.r_map.l_next
$4 = {l_addr = 140737363566592, l_name = 0x3deba1ade4 "", l_ld = 0x7ffff7ffe580, l_next = 0x7ffff7ffd658, l_prev = 0x3debc21188}
(gdb) p/x *_r_debug.r_map.l_next
$5 = {l_addr = 0x7ffff88fe000, l_name = 0x3deba1ade4, l_ld = 0x7ffff7ffe580, l_next = 0x7ffff7ffd658, l_prev = 0x3debc21188}
# (gdb) p/x *new.lm_info
# $5 = {l_addr = 0x0, l_addr_inferior = 0x7ffff88fe000, l_addr_p = 0x0, lm_addr = 0x3debc21718, l_ld = 0x7ffff7ffe580, l_next = 0x7ffff7ffd658, l_prev = 0x3debc21188, l_name = 0x3deba1ade4}
(gdb) info auxv
33   AT_SYSINFO_EHDR      System-supplied DSO's ELF header 0x7ffff7ffe000
(gdb) info proc mappings
      0x7ffff7ffe000     0x7ffff7fff000     0x1000          0                           [vdso]
(gdb) dump memory vdso.bin 0x7ffff7ffe000 0x7ffff7fff000
# readelf -Wa vdso.bin
[...]
  Entry point address:               0xffffffffff700700
[...]
Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            0000000000000000 000000 000000 00      0   0  0
  [ 1] .hash             HASH            ffffffffff700120 000120 000038 04   A  2   0  8
  [ 2] .dynsym           DYNSYM          ffffffffff700158 000158 0000d8 18   A  3   2  8
[...]
  [ 9] .dynamic          DYNAMIC         ffffffffff700580 000580 0000f0 10  WA  3   0  8
  

On 09/20/2014 10:30 PM, Jan Kratochvil wrote:
> On Fri, 19 Sep 2014 16:41:34 +0200, Pedro Alves wrote:
>> Here it is.  WDYT?
> [...]
>> --- a/gdb/solib-svr4.c
>> +++ b/gdb/solib-svr4.c
> [...]
>> @@ -1478,6 +1479,42 @@ svr4_current_sos (void)
>>    return svr4_current_sos_direct (info);
>>  }
>>
>> +/* Implement the "current_sos" target_so_ops method.  */
>> +
>> +static struct so_list *
>> +svr4_current_sos (void)
>> +{
>> +  struct so_list *so_head = svr4_current_sos_1 ();
>> +  struct objfile *objfile;
>> +  struct obj_section *osect;
>> +  CORE_ADDR vsyscall_addr = gdbarch_vsyscall_address (target_gdbarch ());
>> +
>> +  /* Filter out the vDSO module, if present.  Its symbol file would
>> +     not be found on disk.  The vDSO/vsyscall's OBJFILE is instead
>> +     managed by symfile-mem.c:add_vsyscall_page.  */
>> +  if (vsyscall_addr != 0)
>> +    {
>> +      struct so_list **sop;
>> +
>> +      sop = &so_head;
>> +      while (*sop != NULL)
>> +	{
>> +	  struct so_list *so = *sop;
>> +
>> +	  if (so->lm_info->l_addr_inferior == vsyscall_addr)
> 
> This won't work as l_addr_inferior (and also l_addr) do not necessarily
> represent the real starting address of the ELF if the ELF itself is
> "prelinked".  For some reason vDSOs on some kernels look like prelinked.
> 
> kernel-3.16.2-200.fc20.x86_64 appears sane, vDSO is 0-based.
> 
> But for example kernel-2.6.32-220.el6.x86_64 is "prelinked", see below.

Ah, didn't know that.  That's the sort of thing we should have in
comments in the code, or at least in the commit log.

> That's the pain of solib-svr4.c which is OS-agnostic and so it cannot find out
> start of the ELF file just from link map.  gdbserver can find it as it can
> depend on /proc/PID/{s,}maps as its linux-low.c is Linux-specific.

Is it really a pain though?  We can just put things behind gdbarch hooks,
like my patch was doing.  In fact, symfile-mem.c is already looking
at /proc/PID/maps to find the vdso mapping size.  That's exactly done
behind a gdbarch hook:

      args.size = 0;
      if (gdbarch_find_memory_regions_p (target_gdbarch ()))
	(void) gdbarch_find_memory_regions (target_gdbarch (),
					    find_vdso_size, &args);

> 
> kernel-2.6.32-220.el6.x86_64
> (gdb) p *_r_debug.r_map.l_next
> $4 = {l_addr = 140737363566592, l_name = 0x3deba1ade4 "", l_ld = 0x7ffff7ffe580, l_next = 0x7ffff7ffd658, l_prev = 0x3debc21188}
> (gdb) p/x *_r_debug.r_map.l_next
> $5 = {l_addr = 0x7ffff88fe000, l_name = 0x3deba1ade4, l_ld = 0x7ffff7ffe580, l_next = 0x7ffff7ffd658, l_prev = 0x3debc21188}
> # (gdb) p/x *new.lm_info
> # $5 = {l_addr = 0x0, l_addr_inferior = 0x7ffff88fe000, l_addr_p = 0x0, lm_addr = 0x3debc21718, l_ld = 0x7ffff7ffe580, l_next = 0x7ffff7ffd658, l_prev = 0x3debc21188, l_name = 0x3deba1ade4}
> (gdb) info auxv
> 33   AT_SYSINFO_EHDR      System-supplied DSO's ELF header 0x7ffff7ffe000
> (gdb) info proc mappings
>       0x7ffff7ffe000     0x7ffff7fff000     0x1000          0                           [vdso]

Sounds like a predicate like this would work then?

	  if (vsyscall_start <= so->lm_info->l_ld && so->lm_info->l_ld < vsyscall_end)

We would move the bit that finds the vdso size to the gdbarch_vsyscall_address hook,
and make that new hook return the vsyscall's size too in addition to
the starting address.  We can also cache the result somewhere instead
of constantly reopening /proc/PID/maps if necessary.

We can also add a custom linux-specific target_so_ops implementation that
extends svr4's if we want.  The target_so_ops to use is also registered
in the gdbarch.

  CORE_ADDR vsyscall_start;
  CORE_ADDR vsyscall_end;

  vsyscall_start = gdbarch_vsyscall_address (target_gdbarch (), &vsyscall_end);

  /* Filter out the vDSO module, if present.  Its symbol file would
     not be found on disk.  The vDSO/vsyscall's OBJFILE is instead
     managed by symfile-mem.c:add_vsyscall_page.  */
  if (vsyscall_start != 0)
    {
       struct so_list **sop;

       sop = &so_head;
       while (*sop != NULL)
         {
           struct so_list *so = *sop;

    	   if (vsyscall_start <= so->lm_info->l_ld
               && so->lm_info->l_ld < vsyscall_end)
             {
               ... found vdso ...

> (gdb) dump memory vdso.bin 0x7ffff7ffe000 0x7ffff7fff000
> # readelf -Wa vdso.bin
> [...]
>   Entry point address:               0xffffffffff700700
> [...]
> Section Headers:
>   [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
>   [ 0]                   NULL            0000000000000000 000000 000000 00      0   0  0
>   [ 1] .hash             HASH            ffffffffff700120 000120 000038 04   A  2   0  8
>   [ 2] .dynsym           DYNSYM          ffffffffff700158 000158 0000d8 18   A  3   2  8
> [...]
>   [ 9] .dynamic          DYNAMIC         ffffffffff700580 000580 0000f0 10  WA  3   0  8

Thanks,
Pedro Alves
  

On Sun, 21 Sep 2014 21:12:17 +0200, Pedro Alves wrote:
> On 09/20/2014 10:30 PM, Jan Kratochvil wrote:
> > But for example kernel-2.6.32-220.el6.x86_64 is "prelinked", see below.
> 
> Ah, didn't know that.  That's the sort of thing we should have in
> comments in the code, or at least in the commit log.

That apparently would not work, comment is added only after the problem is
discovered.

It would be found by automated testing upon submitting patch for reviews, such
as I have seen done through Jenkins connected to Gerrit.

At least assuming the same "prelinked vDSO" (which is definitely not done by
the prelink program) issue also happens on some non-Fedora/non-RHEL OSes
(as Fedora/RHEL OSes have patched glibc where the vDSO is not listed in the
link map at all and so the patch being discussed is not needed there).

And sure deploying automated testing with the current GDB testsuite as is
would not work now automatically as the testsuite has fuzzy results.  Although
at least running new testcases (from the patch under review) would work which
would be sufficient in this case (but not in other cases - regression cases).


Jan
  

On 09/23/2014 11:58 AM, Jan Kratochvil wrote:
> On Sun, 21 Sep 2014 21:12:17 +0200, Pedro Alves wrote:
>> On 09/20/2014 10:30 PM, Jan Kratochvil wrote:
>>> But for example kernel-2.6.32-220.el6.x86_64 is "prelinked", see below.
>>
>> Ah, didn't know that.  That's the sort of thing we should have in
>> comments in the code, or at least in the commit log.
> 
> That apparently would not work, comment is added only after the problem is
> discovered.

:-)  Ah, OK.  I thought that that was already the reason you
didn't match the vDSO using AT_SYSINFO_EHDR in your original patch.

> It would be found by automated testing upon submitting patch for reviews, such
> as I have seen done through Jenkins connected to Gerrit.

Or even after the patch is in, and we can revert if build / test bots
find a problem.  Seems like a simpler step that I don't think anyone
would object to ...

Seems like Jan-Benedict Glaw is running a buildbot that includes GDB:

  http://toolchain.lug-owl.de/buildbot/

No idea what system that runs on, and whether he runs the testsuite
as well.

Sergio was also interested in setting up a GDB build bot.

There's the gcc compile farm too.

> And sure deploying automated testing with the current GDB testsuite as is
> would not work now automatically as the testsuite has fuzzy results.

We should be able to filter those out though.  Of course ideally we'd
just fix them to not be fuzzy...

> Although at least running new testcases (from the patch under review) would work which
> would be sufficient in this case (but not in other cases - regression cases).

Thanks,
Pedro Alves
  

On Tue, 23 Sep 2014 14:32:32 +0200, Pedro Alves wrote:
> :-)  Ah, OK.  I thought that that was already the reason you
> didn't match the vDSO using AT_SYSINFO_EHDR in your original patch.

OK, true, I could make some such patch already in the original patch but
I found that part obvious. :-)


> > It would be found by automated testing upon submitting patch for reviews, such
> > as I have seen done through Jenkins connected to Gerrit.
> 
> Or even after the patch is in, and we can revert if build / test bots
> find a problem.  Seems like a simpler step that I don't think anyone
> would object to ...

I find the primary advantage that it tests the patches already before review.
The same way the patches are automatically checked for proper code formatting.
So one no longer has to lose time on those mechanical parts during reviews,
which is one of the reasons I stopped doing them regularly (if I ever did).


> Seems like Jan-Benedict Glaw is running a buildbot that includes GDB:
> Sergio was also interested in setting up a GDB build bot.
> There's the gcc compile farm too.

I do not know who is running which bots but so far it seems to me I am the
only one paying some attention to their results - or are there other
regression bugreports I miss on the list?


> We should be able to filter those out though.  Of course ideally we'd
> just fix them to not be fuzzy...

I do not see how to filter them automatically.  The gdb.mi/mi-nsintrall.exp
regression today looks exactly like one of the many nightly fuzzy results but
in the end it has proven to be a real regression.


Jan
  

On 09/23/2014 01:45 PM, Jan Kratochvil wrote:

>> Seems like Jan-Benedict Glaw is running a buildbot that includes GDB:
>> Sergio was also interested in setting up a GDB build bot.
>> There's the gcc compile farm too.
> 
> I do not know who is running which bots but so far it seems to me I am the
> only one paying some attention to their results - or are there other
> regression bugreports I miss on the list?

On testing regressions, indeed you may the only one doing
something like that currently.  Is your build/test bot some
place public others can look at results?

I saw Jan-Benedict acting on a build regression caught by the
build bot here:

  https://sourceware.org/ml/gdb-patches/2014-09/msg00658.html

Seems like we should at least have a central place that lists
the existing public bots / auto testers.  Like, a wiki page.  :-)

Thanks,
Pedro Alves
  

On Tue, 23 Sep 2014 15:30:14 +0200, Pedro Alves wrote:
> On testing regressions, indeed you may the only one doing
> something like that currently.  Is your build/test bot some
> place public others can look at results?

Sanimir Agovic asked for results subscription in the past, it had no public
access so far as I am still waiting till some more "business ran" testing bot
gets deployed.  So I made accessible what I have now ...


> Seems like we should at least have a central place that lists
> the existing public bots / auto testers.  Like, a wiki page.  :-)

... at the wiki page:
	https://sourceware.org/gdb/wiki/BuildBotResults
	https://sourceware.org/gdb/wiki/HomePageDevelopingColumn?action=diff&rev2=33&rev1=32


> I saw Jan-Benedict acting on a build regression caught by the
> build bot here:
> 
>   https://sourceware.org/ml/gdb-patches/2014-09/msg00658.html

OK, great, I see there is running second testbot.


Jan
  

On Tue, Sep 23, 2014 at 3:58 AM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> And sure deploying automated testing with the current GDB testsuite as is
> would not work now automatically as the testsuite has fuzzy results.  Although
> at least running new testcases (from the patch under review) would work which
> would be sufficient in this case (but not in other cases - regression cases).

Sometimes tests are flaky and one isn't aware of it, and not
everything gets caught by patch review.

IWBN if automated testing reran everything failing test N times (10?)
and reported those results as something like "fail" (always failed) or
"flaky" (inconsistent).
  

On 09/23/2014 02:57 PM, Jan Kratochvil wrote:
> On Tue, 23 Sep 2014 15:30:14 +0200, Pedro Alves wrote:
>> On testing regressions, indeed you may the only one doing
>> something like that currently.  Is your build/test bot some
>> place public others can look at results?
> 
> Sanimir Agovic asked for results subscription in the past, it had no public
> access so far as I am still waiting till some more "business ran" testing bot
> gets deployed.  So I made accessible what I have now ...

Thanks!

(fyi, http://host2.jankratochvil.net/gdbmail seems to not be working for me atm.)

I think it'd be fine to send the periodic email results/alerts/whatever to:

 https://sourceware.org/ml/gdb-testresults/

That list hasn't been active in a while, but it's still alive, afaics,
and the point of that list was to collect auto testers' test results.

>> Seems like we should at least have a central place that lists
>> the existing public bots / auto testers.  Like, a wiki page.  :-)
> 
> ... at the wiki page:
> 	https://sourceware.org/gdb/wiki/BuildBotResults
> 	https://sourceware.org/gdb/wiki/HomePageDevelopingColumn?action=diff&rev2=33&rev1=32

Awesome, thank you.

>> I saw Jan-Benedict acting on a build regression caught by the
>> build bot here:
>>
>>   https://sourceware.org/ml/gdb-patches/2014-09/msg00658.html
> 
> OK, great, I see there is running second testbot.

Thanks,
Pedro Alves
  

On Tue, Sep 23, 2014 at 5:45 AM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> I find the primary advantage that it tests the patches already before review.

That would indeed be awesome.
  

On 09/23/2014 03:48 PM, Doug Evans wrote:
> On Tue, Sep 23, 2014 at 3:58 AM, Jan Kratochvil
> <jan.kratochvil@redhat.com> wrote:
>> And sure deploying automated testing with the current GDB testsuite as is
>> would not work now automatically as the testsuite has fuzzy results.  Although
>> at least running new testcases (from the patch under review) would work which
>> would be sufficient in this case (but not in other cases - regression cases).
> 
> Sometimes tests are flaky and one isn't aware of it, and not
> everything gets caught by patch review.
> 
> IWBN if automated testing reran everything failing test N times (10?)
> and reported those results as something like "fail" (always failed) or
> "flaky" (inconsistent).

Indeed.  I think that would be doable as part of gdb's own
testsuite machinery even, which would make it easily available
to every one.

Thanks,
Pedro Alves
  

On 2014-09-23 08:32 AM, Pedro Alves wrote:
>> And sure deploying automated testing with the current GDB testsuite as is
>> would not work now automatically as the testsuite has fuzzy results.
> 
> We should be able to filter those out though.  Of course ideally we'd
> just fix them to not be fuzzy...

If we adopt automated testing as part of the process and those fuzzy tests are
in the way, it will help identify them and it will give some a motivation to fix
them.

What is bugging me is also the failing test cases in master. In order to make
Jenkins (or similar) useful, you need a baseline where everything is green.
Otherwise all patches that will get tested will fail and it will be difficult
to weed out the actually failing patches from the good ones.

Unless there is actually a way to make a pass/fail/unresolved "diff" that
compares the patch's results to those of the latest master commit's results.
Last time I checked, it didn't seem obvious.

Simon
  

On Tue, 23 Sep 2014 16:48:50 +0200, Pedro Alves wrote:
https://sourceware.org/gdb/wiki/BuildBotResults
->
> (fyi, http://host2.jankratochvil.net/gdbmail seems to not be working for me atm.)

The only idea I have is you still do not have IPv6 connectivity.


> I think it'd be fine to send the periodic email results/alerts/whatever to:
> 
>  https://sourceware.org/ml/gdb-testresults/

I have set up that address, we'll see tomorrow.  I did not know that list.


Jan
  

On 09/23/2014 04:53 PM, Jan Kratochvil wrote:
> On Tue, 23 Sep 2014 16:48:50 +0200, Pedro Alves wrote:
> https://sourceware.org/gdb/wiki/BuildBotResults
> ->
>> (fyi, http://host2.jankratochvil.net/gdbmail seems to not be working for me atm.)
> 
> The only idea I have is you still do not have IPv6 connectivity.

Yes, that's right.

>> I think it'd be fine to send the periodic email results/alerts/whatever to:
>>
>>  https://sourceware.org/ml/gdb-testresults/
> 
> I have set up that address, we'll see tomorrow.  I did not know that list.

Awesome, progress.  :-)

Thanks,
Pedro Alves
  

On Tue, Sep 23 2014, Pedro Alves wrote:

> I think it'd be fine to send the periodic email results/alerts/whatever to:
>
>  https://sourceware.org/ml/gdb-testresults/
>
> That list hasn't been active in a while, but it's still alive, afaics,
> and the point of that list was to collect auto testers' test results.

Interesting.  Even before I started working on GDB, Andreas Krebbel had
set up a bot that sends test results to a different list, and we're
still continuing to do so:

  https://sourceware.org/ml/gdb-testers/

Knowing now that there's also gdb-testresults, I wonder whether that
ever was a good choice.  We could certainly change that, so gdb-testers
is freed up for discussions like this one ;-)