GDB 16.0.90 available for testing

GDB 16.0.90 available for testing

[Joel Brobecker]

Hello,

I have just finished creating the gdb-16.0.90 pre-release.
It is available for download at the following location:

    https://sourceware.org/pub/gdb/snapshots/branch/gdb-16.0.90.tar.xz

A gzip'ed version is also available: gdb-16.0.90.tar.gz.

Please give it a test if you can and report any problems you might find.

On behalf of all the GDB contributors, thank you!
-- 
Joel Brobecker

Re: GDB 16.0.90 available for testing

[Eli Zaretskii]

> From: Joel Brobecker <brobecker@adacore.com>
> Date: Sun, 29 Dec 2024 07:31:30 +0400 (+04)
> 
> I have just finished creating the gdb-16.0.90 pre-release.
> It is available for download at the following location:
> 
>     https://sourceware.org/pub/gdb/snapshots/branch/gdb-16.0.90.tar.xz
> 
> A gzip'ed version is also available: gdb-16.0.90.tar.gz.
> 
> Please give it a test if you can and report any problems you might find.

I've built this pretest with mingw.org's MinGW (GCC 9.2.0), as 32-bit
GDB executable for native Windows debugging, and found the following
problems:

1. A compilation error in readline/input.c, due to lack of 'alarm'
function.  I have reported that several months ago to the upstream
Readline developers, but the solution they installed only works for
MinGW64.  For mingw.org we need the following patch:

--- readline/readline/input.c~0	2024-12-29 04:50:07.000000000 +0200
+++ readline/readline/input.c	2024-12-29 12:32:04.196630800 +0200
@@ -151,6 +151,14 @@ win32_isatty (int fd)
 #  define RL_TIMEOUT_USE_SELECT
 #else
 #  define RL_TIMEOUT_USE_SIGALRM
+#  ifdef __MINGW32_MAJOR_VERSION
+/* mingw.org's MinGW doesn't have 'alarm'.  */
+unsigned int
+alarm (unsigned int seconds)
+{
+  return 0;
+}
+#  endif
 #endif
 
 int rl_set_timeout (unsigned int, unsigned int);

2. Compilation error in event-top.c:


       CXX    event-top.o
     In file included from d:\usr\include\winsock2.h:69,
		      from ./../gdbsupport/gdb_select.h:30,
		      from event-top.c:43:
     event-top.c: In function 'fd_set* fd_copy(fd_set*, const fd_set*, int)':
     event-top.c:1279:22: error: invalid conversion from 'const fd_set*' to 'fd_set*' [-fpermissive]
      1279 |     if (FD_ISSET (i, src))
	   |                      ^
	   |                      |
	   |                      const fd_set*
     d:\usr\include\winsock.h:164:50: note:   initializing argument 2 of 'int __FD_ISSET(SOCKET, fd_set*)'
       164 | __CRT_ALIAS int __FD_ISSET( SOCKET __fd, fd_set *__set )
	   |                                          ~~~~~~~~^~~~~

I solved it with an explicit cast, like this:

--- gdb/event-top.c~0	2024-12-29 04:50:07.000000000 +0200
+++ gdb/event-top.c	2024-12-29 12:33:48.356713700 +0200
@@ -1276,7 +1276,7 @@ fd_copy (fd_set *dst, const fd_set *src,
 {
   FD_ZERO (dst);
   for (int i = 0; i < n; ++i)
-    if (FD_ISSET (i, src))
+    if (FD_ISSET (i, (fd_set *)src))
       FD_SET (i, dst);
 
   return dst;

But I don't know if this will produce problems for other
implementations of FD_ISSET.

3. Running GDB on itself produces the following error message:

  warning: BFD: error: d:\gnu\gdb-16.0.90\gdb\gdb.exe(.debug_macro) is too large (0x9f585e077fdeba bytes)
  warning: Can't read data for section '.debug_macro' in file 'd:\gnu\gdb-16.0.90\gdb\gdb.exe'
  During symbol reading: missing .debug_macro section

The size of the section is obviously bogus; the real size is 0x77fdeba
bytes, which is more than 128 MBytes, and so fails malloc.  I tracked
the bogus print value to this code in bfd:

	      /* PR 20801: Provide a more helpful error message.  */
	      if (bfd_get_error () == bfd_error_no_memory)
		_bfd_error_handler
		  /* xgettext:c-format */
		  (_("error: %pB(%pA) is too large (%#" PRIx64 " bytes)"),
		  abfd, sec, (uint64_t) allocsz);

It sounds like uint64_t values are not printed correctly by BFD in
this 32-bit build?  I ended up using the following kludge:

		  if (sizeof (allocsz ) > sizeof (int))
		    _bfd_error_handler
		    /* xgettext:c-format */
		      (_("error: %pB(%pA) is too large (%#" PRIx64 " bytes)"),
		       abfd, sec, (uint64_t) allocsz);
		  else
		    _bfd_error_handler
		    /* xgettext:c-format */
		      (_("error: %pB(%pA) is too large (%#" PRIx32 " bytes)"),
		       abfd, sec, allocsz);

4. Running "maint selftest" finds one failure:

  Running selftest help_doc_invariants.
  help doc broken invariant: command 'signal-event' help doc has over-long line
  Self test failed: self-test failed at unittests/command-def-selftests.c:121

I fixed that with the following trivial change:

--- gdb/windows-nat.c~0	2024-12-29 04:50:07.000000000 +0200
+++ gdb/windows-nat.c	2024-12-29 12:54:32.346946000 +0200
@@ -3114,9 +3114,9 @@ _initialize_windows_nat ()
 
   add_com ("signal-event", class_run, signal_event_command, _("\
 Signal a crashed process with event ID, to allow its debugging.\n\
-This command is needed in support of setting up GDB as JIT debugger on \
-MS-Windows.  The command should be invoked from the GDB command line using \
-the '-ex' command-line option.  The ID of the event that blocks the \
+This command is needed in support of setting up GDB as JIT debugger on\n\
+MS-Windows.  The command should be invoked from the GDB command line using\n\
+the '-ex' command-line option.  The ID of the event that blocks the\n\
 crashed process will be supplied by the Windows JIT debugging mechanism."));
 
 #ifdef __CYGWIN__

I will report items 1 and 3 to the corresponding upstream projects,
but is it okay to meanwhile install the patches above on the
gdb-16-branch?

And what about items 2 and 4 -- can I install their fixes?  The fix
with type-cast for FD_ISSET is something I'm unsure about.

Thanks.

Re: GDB 16.0.90 available for testing

[Hannes Domani]

 Am Sonntag, 29. Dezember 2024 um 13:55:25 MEZ hat Eli Zaretskii <eliz@gnu.org> Folgendes geschrieben:

> > From: Joel Brobecker <brobecker@adacore.com>
> > Date: Sun, 29 Dec 2024 07:31:30 +0400 (+04)
> >
> > I have just finished creating the gdb-16.0.90 pre-release.
> > It is available for download at the following location:
> >
> >    https://sourceware.org/pub/gdb/snapshots/branch/gdb-16.0.90.tar.xz
> >
> > A gzip'ed version is also available: gdb-16.0.90.tar.gz.
> >
> > Please give it a test if you can and report any problems you might find.
>
> I've built this pretest with mingw.org's MinGW (GCC 9.2.0), as 32-bit
> GDB executable for native Windows debugging, and found the following
>
> problems:
>
>
> 1. A compilation error in readline/input.c, due to lack of 'alarm'
> function.  I have reported that several months ago to the upstream
> Readline developers, but the solution they installed only works for
> MinGW64.  For mingw.org we need the following patch:
>
> --- readline/readline/input.c~0    2024-12-29 04:50:07.000000000 +0200
> +++ readline/readline/input.c    2024-12-29 12:32:04.196630800 +0200
> @@ -151,6 +151,14 @@ win32_isatty (int fd)
> #  define RL_TIMEOUT_USE_SELECT
> #else
> #  define RL_TIMEOUT_USE_SIGALRM
> +#  ifdef __MINGW32_MAJOR_VERSION
> +/* mingw.org's MinGW doesn't have 'alarm'.  */
> +unsigned int
> +alarm (unsigned int seconds)
> +{
> +  return 0;
> +}
> +#  endif
> #endif
>
> int rl_set_timeout (unsigned int, unsigned int);

I wonder why readline doesn't disable the whole stuff where alarm is used
on windows, since it doesn't work there anyways.


> 2. Compilation error in event-top.c:
>
>
>       CXX    event-top.o
>     In file included from d:\usr\include\winsock2.h:69,
>               from ./../gdbsupport/gdb_select.h:30,
>               from event-top.c:43:
>     event-top.c: In function 'fd_set* fd_copy(fd_set*, const fd_set*, int)':
>     event-top.c:1279:22: error: invalid conversion from 'const fd_set*' to 'fd_set*' [-fpermissive]
>       1279 |    if (FD_ISSET (i, src))
>       |                      ^
>       |                      |
>       |                      const fd_set*
>     d:\usr\include\winsock.h:164:50: note:  initializing argument 2 of 'int __FD_ISSET(SOCKET, fd_set*)'
>       164 | __CRT_ALIAS int __FD_ISSET( SOCKET __fd, fd_set *__set )
>       |                                          ~~~~~~~~^~~~~
>
> I solved it with an explicit cast, like this:
>
> --- gdb/event-top.c~0    2024-12-29 04:50:07.000000000 +0200
> +++ gdb/event-top.c    2024-12-29 12:33:48.356713700 +0200
> @@ -1276,7 +1276,7 @@ fd_copy (fd_set *dst, const fd_set *src,
> {
>   FD_ZERO (dst);
>   for (int i = 0; i < n; ++i)
> -    if (FD_ISSET (i, src))
> +    if (FD_ISSET (i, (fd_set *)src))
>       FD_SET (i, dst);
>
>   return dst;
>
> But I don't know if this will produce problems for other
> implementations of FD_ISSET.
>
> 3. Running GDB on itself produces the following error message:
>
>   warning: BFD: error: d:\gnu\gdb-16.0.90\gdb\gdb.exe(.debug_macro) is too large (0x9f585e077fdeba bytes)
>   warning: Can't read data for section '.debug_macro' in file 'd:\gnu\gdb-16.0.90\gdb\gdb.exe'
>   During symbol reading: missing .debug_macro section
>
> The size of the section is obviously bogus; the real size is 0x77fdeba
> bytes, which is more than 128 MBytes, and so fails malloc.  I tracked
> the bogus print value to this code in bfd:
>
>           /* PR 20801: Provide a more helpful error message.  */
>           if (bfd_get_error () == bfd_error_no_memory)
>         _bfd_error_handler
>           /* xgettext:c-format */
>           (_("error: %pB(%pA) is too large (%#" PRIx64 " bytes)"),
>           abfd, sec, (uint64_t) allocsz);
>
> It sounds like uint64_t values are not printed correctly by BFD in
> this 32-bit build?  I ended up using the following kludge:
>
>           if (sizeof (allocsz ) > sizeof (int))
>             _bfd_error_handler
>             /* xgettext:c-format */
>               (_("error: %pB(%pA) is too large (%#" PRIx64 " bytes)"),
>               abfd, sec, (uint64_t) allocsz);
>           else
>             _bfd_error_handler
>             /* xgettext:c-format */
>               (_("error: %pB(%pA) is too large (%#" PRIx32 " bytes)"),
>               abfd, sec, allocsz);

Doesn't the (uint64_t) cast already make sure the allocsz value matches
PRIx64, so why does it not work here?

What does PRIx64 expand to for you, "llx" or "I64x"?
_bfd_print can only handle llx as far as I can tell, and in my build this is
automatically enabled by the __USE_MINGW_ANSI_STDIO define.


> 4. Running "maint selftest" finds one failure:
>
>   Running selftest help_doc_invariants.
>   help doc broken invariant: command 'signal-event' help doc has over-long line
>   Self test failed: self-test failed at unittests/command-def-selftests.c:121
>
> I fixed that with the following trivial change:
>
> --- gdb/windows-nat.c~0    2024-12-29 04:50:07.000000000 +0200
> +++ gdb/windows-nat.c    2024-12-29 12:54:32.346946000 +0200
> @@ -3114,9 +3114,9 @@ _initialize_windows_nat ()
>
>   add_com ("signal-event", class_run, signal_event_command, _("\
> Signal a crashed process with event ID, to allow its debugging.\n\
> -This command is needed in support of setting up GDB as JIT debugger on \
> -MS-Windows.  The command should be invoked from the GDB command line using \
> -the '-ex' command-line option.  The ID of the event that blocks the \
> +This command is needed in support of setting up GDB as JIT debugger on\n\
> +MS-Windows.  The command should be invoked from the GDB command line using\n\
> +the '-ex' command-line option.  The ID of the event that blocks the\n\
> crashed process will be supplied by the Windows JIT debugging mechanism."));
>
> #ifdef __CYGWIN__
>
> I will report items 1 and 3 to the corresponding upstream projects,
> but is it okay to meanwhile install the patches above on the
> gdb-16-branch?
>
> And what about items 2 and 4 -- can I install their fixes?  The fix
> with type-cast for FD_ISSET is something I'm unsure about.
>
> Thanks.


Hannes

Re: GDB 16.0.90 available for testing

[Eli Zaretskii]

> Date: Sun, 29 Dec 2024 15:11:40 +0000 (UTC)
> From: Hannes Domani <ssbssa@yahoo.de>
> Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
> 
>  Am Sonntag, 29. Dezember 2024 um 13:55:25 MEZ hat Eli Zaretskii <eliz@gnu.org> Folgendes geschrieben:
> 
> > 1. A compilation error in readline/input.c, due to lack of 'alarm'
> > function.  I have reported that several months ago to the upstream
> > Readline developers, but the solution they installed only works for
> > MinGW64.  For mingw.org we need the following patch:
> >
> > --- readline/readline/input.c~0    2024-12-29 04:50:07.000000000 +0200
> > +++ readline/readline/input.c    2024-12-29 12:32:04.196630800 +0200
> > @@ -151,6 +151,14 @@ win32_isatty (int fd)
> > #  define RL_TIMEOUT_USE_SELECT
> > #else
> > #  define RL_TIMEOUT_USE_SIGALRM
> > +#  ifdef __MINGW32_MAJOR_VERSION
> > +/* mingw.org's MinGW doesn't have 'alarm'.  */
> > +unsigned int
> > +alarm (unsigned int seconds)
> > +{
> > +  return 0;
> > +}
> > +#  endif
> > #endif
> >
> > int rl_set_timeout (unsigned int, unsigned int);
> 
> I wonder why readline doesn't disable the whole stuff where alarm is used
> on windows, since it doesn't work there anyways.

Chet said that's what he did, but I saw no evidence of that in the
current Readline (assuming I was looking at the correct branch in the
Git repository).  See

  https://lists.gnu.org/archive/html/bug-readline/2024-12/msg00003.html

> > 3. Running GDB on itself produces the following error message:
> >
> >   warning: BFD: error: d:\gnu\gdb-16.0.90\gdb\gdb.exe(.debug_macro) is too large (0x9f585e077fdeba bytes)
> >   warning: Can't read data for section '.debug_macro' in file 'd:\gnu\gdb-16.0.90\gdb\gdb.exe'
> >   During symbol reading: missing .debug_macro section
> >
> > The size of the section is obviously bogus; the real size is 0x77fdeba
> > bytes, which is more than 128 MBytes, and so fails malloc.  I tracked
> > the bogus print value to this code in bfd:
> >
> >           /* PR 20801: Provide a more helpful error message.  */
> >           if (bfd_get_error () == bfd_error_no_memory)
> >         _bfd_error_handler
> >           /* xgettext:c-format */
> >           (_("error: %pB(%pA) is too large (%#" PRIx64 " bytes)"),
> >           abfd, sec, (uint64_t) allocsz);
> >
> > It sounds like uint64_t values are not printed correctly by BFD in
> > this 32-bit build?  I ended up using the following kludge:
> >
> >           if (sizeof (allocsz ) > sizeof (int))
> >             _bfd_error_handler
> >             /* xgettext:c-format */
> >               (_("error: %pB(%pA) is too large (%#" PRIx64 " bytes)"),
> >               abfd, sec, (uint64_t) allocsz);
> >           else
> >             _bfd_error_handler
> >             /* xgettext:c-format */
> >               (_("error: %pB(%pA) is too large (%#" PRIx32 " bytes)"),
> >               abfd, sec, allocsz);
> 
> Doesn't the (uint64_t) cast already make sure the allocsz value matches
> PRIx64, so why does it not work here?
> 
> What does PRIx64 expand to for you, "llx" or "I64x"?
> _bfd_print can only handle llx as far as I can tell, and in my build this is
> automatically enabled by the __USE_MINGW_ANSI_STDIO define.

AFAICT, llx didn't help, either (I tried), and __USE_MINGW_ANSI_STDIO
is the default anyway.  It's very strange what I saw there, using llx
I got printed values like 0x77fdeba00000000, which seem like the value
was interpreted as big-endian or something?  You are welcome to try,
maybe I was confused or something.

Re: GDB 16.0.90 available for testing

[Eli Zaretskii]

> Date: Sun, 29 Dec 2024 17:33:26 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: brobecker@adacore.com, gdb-patches@sourceware.org
> 
> > > 3. Running GDB on itself produces the following error message:
> > >
> > >   warning: BFD: error: d:\gnu\gdb-16.0.90\gdb\gdb.exe(.debug_macro) is too large (0x9f585e077fdeba bytes)
> > >   warning: Can't read data for section '.debug_macro' in file 'd:\gnu\gdb-16.0.90\gdb\gdb.exe'
> > >   During symbol reading: missing .debug_macro section
> > >
> > > The size of the section is obviously bogus; the real size is 0x77fdeba
> > > bytes, which is more than 128 MBytes, and so fails malloc.  I tracked
> > > the bogus print value to this code in bfd:
> > >
> > >           /* PR 20801: Provide a more helpful error message.  */
> > >           if (bfd_get_error () == bfd_error_no_memory)
> > >         _bfd_error_handler
> > >           /* xgettext:c-format */
> > >           (_("error: %pB(%pA) is too large (%#" PRIx64 " bytes)"),
> > >           abfd, sec, (uint64_t) allocsz);
> > >
> > > It sounds like uint64_t values are not printed correctly by BFD in
> > > this 32-bit build?  I ended up using the following kludge:
> > >
> > >           if (sizeof (allocsz ) > sizeof (int))
> > >             _bfd_error_handler
> > >             /* xgettext:c-format */
> > >               (_("error: %pB(%pA) is too large (%#" PRIx64 " bytes)"),
> > >               abfd, sec, (uint64_t) allocsz);
> > >           else
> > >             _bfd_error_handler
> > >             /* xgettext:c-format */
> > >               (_("error: %pB(%pA) is too large (%#" PRIx32 " bytes)"),
> > >               abfd, sec, allocsz);
> > 
> > Doesn't the (uint64_t) cast already make sure the allocsz value matches
> > PRIx64, so why does it not work here?
> > 
> > What does PRIx64 expand to for you, "llx" or "I64x"?
> > _bfd_print can only handle llx as far as I can tell, and in my build this is
> > automatically enabled by the __USE_MINGW_ANSI_STDIO define.
> 
> AFAICT, llx didn't help, either (I tried), and __USE_MINGW_ANSI_STDIO
> is the default anyway.  It's very strange what I saw there, using llx
> I got printed values like 0x77fdeba00000000, which seem like the value
> was interpreted as big-endian or something?  You are welcome to try,
> maybe I was confused or something.

Alan Modra fixed this bug in Binutils on the master branch, see commit
b38cf91f230b and https://sourceware.org/bugzilla/show_bug.cgi?id=32507

I'd like to apply the patch to gdb-16-branch, so that GDB 16.1 is
released without it.  Do I cherry-pick the commit from master, or do I
follow some other procedure?  That is, when the release tarball of GDB
16.1 is tarred, will it fetch the bfd files from the bfd directory of
the gdb-16-branch branch?

Thanks.

Re: GDB 16.0.90 available for testing

[Joel Brobecker]

> Alan Modra fixed this bug in Binutils on the master branch, see commit
> b38cf91f230b and https://sourceware.org/bugzilla/show_bug.cgi?id=32507
> 
> I'd like to apply the patch to gdb-16-branch, so that GDB 16.1 is
> released without it.  Do I cherry-pick the commit from master, or do I
> follow some other procedure?  That is, when the release tarball of GDB
> 16.1 is tarred, will it fetch the bfd files from the bfd directory of
> the gdb-16-branch branch?

Correct. Binutils and GDB share the same repository, and when we create
the GDB release branches, we branch everything. So backporting fixes
in bfd follows the same procedure as backporting fixes in the gdb
subdirectory (or any other file of the repositotory).

-- 
Joel

Re: GDB 16.0.90 available for testing

[Eli Zaretskii]

> Date: Thu, 2 Jan 2025 05:59:14 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: brobecker@adacore.com, ssbssa@yahoo.de, gdb-patches@sourceware.org
> 
> > Alan Modra fixed this bug in Binutils on the master branch, see commit
> > b38cf91f230b and https://sourceware.org/bugzilla/show_bug.cgi?id=32507
> > 
> > I'd like to apply the patch to gdb-16-branch, so that GDB 16.1 is
> > released without it.  Do I cherry-pick the commit from master, or do I
> > follow some other procedure?  That is, when the release tarball of GDB
> > 16.1 is tarred, will it fetch the bfd files from the bfd directory of
> > the gdb-16-branch branch?
> 
> Correct. Binutils and GDB share the same repository, and when we create
> the GDB release branches, we branch everything. So backporting fixes
> in bfd follows the same procedure as backporting fixes in the gdb
> subdirectory (or any other file of the repositotory).

OK, thanks.  Just to be sure I understand: the repository is shared,
but branches are separate, right?  So when I cherry-pick a commit to
gdb-16-branch, I don't affect any branches that Binutils will use for
their releases, right?  Otherwise, cherry-picking would need to be
coordinated with the Binutils folks.

Re: GDB 16.0.90 available for testing

[Joel Brobecker]

> OK, thanks.  Just to be sure I understand: the repository is shared,
> but branches are separate, right?  So when I cherry-pick a commit to
> gdb-16-branch, I don't affect any branches that Binutils will use for
> their releases, right?  Otherwise, cherry-picking would need to be
> coordinated with the Binutils folks.

Correct!

-- 
Joel

Re: GDB 16.0.90 available for testing

[Eli Zaretskii]

> Date: Thu, 2 Jan 2025 10:48:27 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Joel Brobecker <brobecker@adacore.com>, ssbssa@yahoo.de,
> 	gdb-patches@sourceware.org
> 
> > OK, thanks.  Just to be sure I understand: the repository is shared,
> > but branches are separate, right?  So when I cherry-pick a commit to
> > gdb-16-branch, I don't affect any branches that Binutils will use for
> > their releases, right?  Otherwise, cherry-picking would need to be
> > coordinated with the Binutils folks.
> 
> Correct!

Thanks, so I've now cherry-picked that commit to gdb-16-branch.

Re: GDB 16.0.90 available for testing

[Eli Zaretskii]

> Date: Sun, 29 Dec 2024 17:33:26 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: brobecker@adacore.com, gdb-patches@sourceware.org
> 
> > Date: Sun, 29 Dec 2024 15:11:40 +0000 (UTC)
> > From: Hannes Domani <ssbssa@yahoo.de>
> > Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
> > 
> >  Am Sonntag, 29. Dezember 2024 um 13:55:25 MEZ hat Eli Zaretskii <eliz@gnu.org> Folgendes geschrieben:
> > 
> > > 1. A compilation error in readline/input.c, due to lack of 'alarm'
> > > function.  I have reported that several months ago to the upstream
> > > Readline developers, but the solution they installed only works for
> > > MinGW64.  For mingw.org we need the following patch:
> > >
> > > --- readline/readline/input.c~0    2024-12-29 04:50:07.000000000 +0200
> > > +++ readline/readline/input.c    2024-12-29 12:32:04.196630800 +0200
> > > @@ -151,6 +151,14 @@ win32_isatty (int fd)
> > > #  define RL_TIMEOUT_USE_SELECT
> > > #else
> > > #  define RL_TIMEOUT_USE_SIGALRM
> > > +#  ifdef __MINGW32_MAJOR_VERSION
> > > +/* mingw.org's MinGW doesn't have 'alarm'.  */
> > > +unsigned int
> > > +alarm (unsigned int seconds)
> > > +{
> > > +  return 0;
> > > +}
> > > +#  endif
> > > #endif
> > >
> > > int rl_set_timeout (unsigned int, unsigned int);
> > 
> > I wonder why readline doesn't disable the whole stuff where alarm is used
> > on windows, since it doesn't work there anyways.
> 
> Chet said that's what he did, but I saw no evidence of that in the
> current Readline (assuming I was looking at the correct branch in the
> Git repository).  See
> 
>   https://lists.gnu.org/archive/html/bug-readline/2024-12/msg00003.html

Given what Chet says in

  https://lists.gnu.org/archive/html/bug-readline/2024-12/msg00006.html

I now understand how this is fixed in upstream Readline.  The fix
there is not right: it will fail the MinGW64 build.  So I'd like to
fix this properly in our repository and tell Chet how I recommend to
fix it upstream.

Should I fix this in our repository right away, or would you prefer to
wait for Chet to agree with my proposal, so that we have the same code
as in upstream Readline?

Re: GDB 16.0.90 available for testing

[Eli Zaretskii]

> Date: Sun, 29 Dec 2024 14:54:36 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: gdb-patches@sourceware.org
> 
> 2. Compilation error in event-top.c:
> 
> 
>        CXX    event-top.o
>      In file included from d:\usr\include\winsock2.h:69,
> 		      from ./../gdbsupport/gdb_select.h:30,
> 		      from event-top.c:43:
>      event-top.c: In function 'fd_set* fd_copy(fd_set*, const fd_set*, int)':
>      event-top.c:1279:22: error: invalid conversion from 'const fd_set*' to 'fd_set*' [-fpermissive]
>       1279 |     if (FD_ISSET (i, src))
> 	   |                      ^
> 	   |                      |
> 	   |                      const fd_set*
>      d:\usr\include\winsock.h:164:50: note:   initializing argument 2 of 'int __FD_ISSET(SOCKET, fd_set*)'
>        164 | __CRT_ALIAS int __FD_ISSET( SOCKET __fd, fd_set *__set )
> 	   |                                          ~~~~~~~~^~~~~
> 
> I solved it with an explicit cast, like this:
> 
> --- gdb/event-top.c~0	2024-12-29 04:50:07.000000000 +0200
> +++ gdb/event-top.c	2024-12-29 12:33:48.356713700 +0200
> @@ -1276,7 +1276,7 @@ fd_copy (fd_set *dst, const fd_set *src,
>  {
>    FD_ZERO (dst);
>    for (int i = 0; i < n; ++i)
> -    if (FD_ISSET (i, src))
> +    if (FD_ISSET (i, (fd_set *)src))
>        FD_SET (i, dst);
>  
>    return dst;
> 
> But I don't know if this will produce problems for other
> implementations of FD_ISSET.

No one responded to this part.  Is it okay to fix this, or would
someone please try this first on other platforms?

> 4. Running "maint selftest" finds one failure:
> 
>   Running selftest help_doc_invariants.
>   help doc broken invariant: command 'signal-event' help doc has over-long line
>   Self test failed: self-test failed at unittests/command-def-selftests.c:121
> 
> I fixed that with the following trivial change:
> 
> --- gdb/windows-nat.c~0	2024-12-29 04:50:07.000000000 +0200
> +++ gdb/windows-nat.c	2024-12-29 12:54:32.346946000 +0200
> @@ -3114,9 +3114,9 @@ _initialize_windows_nat ()
>  
>    add_com ("signal-event", class_run, signal_event_command, _("\
>  Signal a crashed process with event ID, to allow its debugging.\n\
> -This command is needed in support of setting up GDB as JIT debugger on \
> -MS-Windows.  The command should be invoked from the GDB command line using \
> -the '-ex' command-line option.  The ID of the event that blocks the \
> +This command is needed in support of setting up GDB as JIT debugger on\n\
> +MS-Windows.  The command should be invoked from the GDB command line using\n\
> +the '-ex' command-line option.  The ID of the event that blocks the\n\
>  crashed process will be supplied by the Windows JIT debugging mechanism."));
>  
>  #ifdef __CYGWIN__

And what about this one? okay to commit?

Re: GDB 16.0.90 available for testing

[Joel Brobecker]

> > > > 1. A compilation error in readline/input.c, due to lack of 'alarm'
> > > > function.  I have reported that several months ago to the upstream
> > > > Readline developers, but the solution they installed only works for
> > > > MinGW64.  For mingw.org we need the following patch:
> > > >
> > > > --- readline/readline/input.c~0    2024-12-29 04:50:07.000000000 +0200
> > > > +++ readline/readline/input.c    2024-12-29 12:32:04.196630800 +0200
> > > > @@ -151,6 +151,14 @@ win32_isatty (int fd)
> > > > #  define RL_TIMEOUT_USE_SELECT
> > > > #else
> > > > #  define RL_TIMEOUT_USE_SIGALRM
> > > > +#  ifdef __MINGW32_MAJOR_VERSION
> > > > +/* mingw.org's MinGW doesn't have 'alarm'.  */
> > > > +unsigned int
> > > > +alarm (unsigned int seconds)
> > > > +{
> > > > +  return 0;
> > > > +}
> > > > +#  endif
> > > > #endif
> > > >
> > > > int rl_set_timeout (unsigned int, unsigned int);
> > > 
> > > I wonder why readline doesn't disable the whole stuff where alarm is used
> > > on windows, since it doesn't work there anyways.
> > 
> > Chet said that's what he did, but I saw no evidence of that in the
> > current Readline (assuming I was looking at the correct branch in the
> > Git repository).  See
> > 
> >   https://lists.gnu.org/archive/html/bug-readline/2024-12/msg00003.html
> 
> Given what Chet says in
> 
>   https://lists.gnu.org/archive/html/bug-readline/2024-12/msg00006.html
> 
> I now understand how this is fixed in upstream Readline.  The fix
> there is not right: it will fail the MinGW64 build.  So I'd like to
> fix this properly in our repository and tell Chet how I recommend to
> fix it upstream.
> 
> Should I fix this in our repository right away, or would you prefer to
> wait for Chet to agree with my proposal, so that we have the same code
> as in upstream Readline?

For the avoidance of doubt, I cannot approve patches in GDB anymore.

With that said, it's been fine in the past to first fix things
locally in GDB, before coordinating with the upstream project
as a second step. When the fix is pushed upstream, we can then
resync our copy if the fix was different.

-- 
Joel

Re: GDB 16.0.90 available for testing

[Luis Machado]

On 1/2/25 17:40, Eli Zaretskii wrote:
>> Date: Sun, 29 Dec 2024 14:54:36 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: gdb-patches@sourceware.org
>>
>> 2. Compilation error in event-top.c:
>>
>>
>>        CXX    event-top.o
>>      In file included from d:\usr\include\winsock2.h:69,
>> 		      from ./../gdbsupport/gdb_select.h:30,
>> 		      from event-top.c:43:
>>      event-top.c: In function 'fd_set* fd_copy(fd_set*, const fd_set*, int)':
>>      event-top.c:1279:22: error: invalid conversion from 'const fd_set*' to 'fd_set*' [-fpermissive]
>>       1279 |     if (FD_ISSET (i, src))
>> 	   |                      ^
>> 	   |                      |
>> 	   |                      const fd_set*
>>      d:\usr\include\winsock.h:164:50: note:   initializing argument 2 of 'int __FD_ISSET(SOCKET, fd_set*)'
>>        164 | __CRT_ALIAS int __FD_ISSET( SOCKET __fd, fd_set *__set )
>> 	   |                                          ~~~~~~~~^~~~~
>>
>> I solved it with an explicit cast, like this:
>>
>> --- gdb/event-top.c~0	2024-12-29 04:50:07.000000000 +0200
>> +++ gdb/event-top.c	2024-12-29 12:33:48.356713700 +0200
>> @@ -1276,7 +1276,7 @@ fd_copy (fd_set *dst, const fd_set *src,
>>  {
>>    FD_ZERO (dst);
>>    for (int i = 0; i < n; ++i)
>> -    if (FD_ISSET (i, src))
>> +    if (FD_ISSET (i, (fd_set *)src))
>>        FD_SET (i, dst);
>>  
>>    return dst;
>>
>> But I don't know if this will produce problems for other
>> implementations of FD_ISSET.
> 
> No one responded to this part.  Is it okay to fix this, or would
> someone please try this first on other platforms?
> 

I gave this a try on aarch64-linux and it builds fine. I see no changes to the
testsuite. 

>> 4. Running "maint selftest" finds one failure:
>>
>>   Running selftest help_doc_invariants.
>>   help doc broken invariant: command 'signal-event' help doc has over-long line
>>   Self test failed: self-test failed at unittests/command-def-selftests.c:121
>>
>> I fixed that with the following trivial change:
>>
>> --- gdb/windows-nat.c~0	2024-12-29 04:50:07.000000000 +0200
>> +++ gdb/windows-nat.c	2024-12-29 12:54:32.346946000 +0200
>> @@ -3114,9 +3114,9 @@ _initialize_windows_nat ()
>>  
>>    add_com ("signal-event", class_run, signal_event_command, _("\
>>  Signal a crashed process with event ID, to allow its debugging.\n\
>> -This command is needed in support of setting up GDB as JIT debugger on \
>> -MS-Windows.  The command should be invoked from the GDB command line using \
>> -the '-ex' command-line option.  The ID of the event that blocks the \
>> +This command is needed in support of setting up GDB as JIT debugger on\n\
>> +MS-Windows.  The command should be invoked from the GDB command line using\n\
>> +the '-ex' command-line option.  The ID of the event that blocks the\n\
>>  crashed process will be supplied by the Windows JIT debugging mechanism."));
>>  
>>  #ifdef __CYGWIN__
> 
> And what about this one? okay to commit?

This looks OK to me, as it is a simple formatting fix for the text. Feel free to
push to master and the 16 branch.

Approved-By: Luis Machado <luis.machado@arm.com>

Re: GDB 16.0.90 available for testing

[Eli Zaretskii]

> Date: Fri, 3 Jan 2025 08:48:51 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: brobecker@adacore.com, Tom Tromey <tom@tromey.com>, ssbssa@yahoo.de,
> 	gdb-patches@sourceware.org
> 
> > > > > 1. A compilation error in readline/input.c, due to lack of 'alarm'
> > > > > function.  I have reported that several months ago to the upstream
> > > > > Readline developers, but the solution they installed only works for
> > > > > MinGW64.  For mingw.org we need the following patch:
> > > > >
> > > > > --- readline/readline/input.c~0    2024-12-29 04:50:07.000000000 +0200
> > > > > +++ readline/readline/input.c    2024-12-29 12:32:04.196630800 +0200
> > > > > @@ -151,6 +151,14 @@ win32_isatty (int fd)
> > > > > #  define RL_TIMEOUT_USE_SELECT
> > > > > #else
> > > > > #  define RL_TIMEOUT_USE_SIGALRM
> > > > > +#  ifdef __MINGW32_MAJOR_VERSION
> > > > > +/* mingw.org's MinGW doesn't have 'alarm'.  */
> > > > > +unsigned int
> > > > > +alarm (unsigned int seconds)
> > > > > +{
> > > > > +  return 0;
> > > > > +}
> > > > > +#  endif
> > > > > #endif
> > > > >
> > > > > int rl_set_timeout (unsigned int, unsigned int);
> > > > 
> > > > I wonder why readline doesn't disable the whole stuff where alarm is used
> > > > on windows, since it doesn't work there anyways.
> > > 
> > > Chet said that's what he did, but I saw no evidence of that in the
> > > current Readline (assuming I was looking at the correct branch in the
> > > Git repository).  See
> > > 
> > >   https://lists.gnu.org/archive/html/bug-readline/2024-12/msg00003.html
> > 
> > Given what Chet says in
> > 
> >   https://lists.gnu.org/archive/html/bug-readline/2024-12/msg00006.html
> > 
> > I now understand how this is fixed in upstream Readline.  The fix
> > there is not right: it will fail the MinGW64 build.  So I'd like to
> > fix this properly in our repository and tell Chet how I recommend to
> > fix it upstream.
> > 
> > Should I fix this in our repository right away, or would you prefer to
> > wait for Chet to agree with my proposal, so that we have the same code
> > as in upstream Readline?
> 
> For the avoidance of doubt, I cannot approve patches in GDB anymore.
> 
> With that said, it's been fine in the past to first fix things
> locally in GDB, before coordinating with the upstream project
> as a second step. When the fix is pushed upstream, we can then
> resync our copy if the fix was different.

Thanks, I've now installed the change on both master and
gdb-16-branch.  Upon taking a better look on what the upstream
Readline did, I came to the conclusion that it does TRT for both
flavors of MinGW, so there's nothing to report to the Readline
developers.

Re: GDB 16.0.90 available for testing

[Eli Zaretskii]

> Date: Fri, 3 Jan 2025 10:05:14 +0000
> Cc: gdb-patches@sourceware.org
> From: Luis Machado <luis.machado@arm.com>
> 
> On 1/2/25 17:40, Eli Zaretskii wrote:
> >> Date: Sun, 29 Dec 2024 14:54:36 +0200
> >> From: Eli Zaretskii <eliz@gnu.org>
> >> Cc: gdb-patches@sourceware.org
> >>
> >> 2. Compilation error in event-top.c:
> >>
> >>
> >>        CXX    event-top.o
> >>      In file included from d:\usr\include\winsock2.h:69,
> >> 		      from ./../gdbsupport/gdb_select.h:30,
> >> 		      from event-top.c:43:
> >>      event-top.c: In function 'fd_set* fd_copy(fd_set*, const fd_set*, int)':
> >>      event-top.c:1279:22: error: invalid conversion from 'const fd_set*' to 'fd_set*' [-fpermissive]
> >>       1279 |     if (FD_ISSET (i, src))
> >> 	   |                      ^
> >> 	   |                      |
> >> 	   |                      const fd_set*
> >>      d:\usr\include\winsock.h:164:50: note:   initializing argument 2 of 'int __FD_ISSET(SOCKET, fd_set*)'
> >>        164 | __CRT_ALIAS int __FD_ISSET( SOCKET __fd, fd_set *__set )
> >> 	   |                                          ~~~~~~~~^~~~~
> >>
> >> I solved it with an explicit cast, like this:
> >>
> >> --- gdb/event-top.c~0	2024-12-29 04:50:07.000000000 +0200
> >> +++ gdb/event-top.c	2024-12-29 12:33:48.356713700 +0200
> >> @@ -1276,7 +1276,7 @@ fd_copy (fd_set *dst, const fd_set *src,
> >>  {
> >>    FD_ZERO (dst);
> >>    for (int i = 0; i < n; ++i)
> >> -    if (FD_ISSET (i, src))
> >> +    if (FD_ISSET (i, (fd_set *)src))
> >>        FD_SET (i, dst);
> >>  
> >>    return dst;
> >>
> >> But I don't know if this will produce problems for other
> >> implementations of FD_ISSET.
> > 
> > No one responded to this part.  Is it okay to fix this, or would
> > someone please try this first on other platforms?
> > 
> 
> I gave this a try on aarch64-linux and it builds fine. I see no changes to the
> testsuite. 
> 
> >> 4. Running "maint selftest" finds one failure:
> >>
> >>   Running selftest help_doc_invariants.
> >>   help doc broken invariant: command 'signal-event' help doc has over-long line
> >>   Self test failed: self-test failed at unittests/command-def-selftests.c:121
> >>
> >> I fixed that with the following trivial change:
> >>
> >> --- gdb/windows-nat.c~0	2024-12-29 04:50:07.000000000 +0200
> >> +++ gdb/windows-nat.c	2024-12-29 12:54:32.346946000 +0200
> >> @@ -3114,9 +3114,9 @@ _initialize_windows_nat ()
> >>  
> >>    add_com ("signal-event", class_run, signal_event_command, _("\
> >>  Signal a crashed process with event ID, to allow its debugging.\n\
> >> -This command is needed in support of setting up GDB as JIT debugger on \
> >> -MS-Windows.  The command should be invoked from the GDB command line using \
> >> -the '-ex' command-line option.  The ID of the event that blocks the \
> >> +This command is needed in support of setting up GDB as JIT debugger on\n\
> >> +MS-Windows.  The command should be invoked from the GDB command line using\n\
> >> +the '-ex' command-line option.  The ID of the event that blocks the\n\
> >>  crashed process will be supplied by the Windows JIT debugging mechanism."));
> >>  
> >>  #ifdef __CYGWIN__
> > 
> > And what about this one? okay to commit?
> 
> This looks OK to me, as it is a simple formatting fix for the text. Feel free to
> push to master and the 16 branch.
> 
> Approved-By: Luis Machado <luis.machado@arm.com>

Thanks, I've now installed both changes on the master branch and then
cherry-picked them to gdb-16-branch.

Re: GDB 16.0.90 available for testing

[Tom de Vries]

On 1/4/25 11:30, Eli Zaretskii wrote:
>> Date: Fri, 3 Jan 2025 10:05:14 +0000
>> Cc: gdb-patches@sourceware.org
>> From: Luis Machado <luis.machado@arm.com>
>>
>> On 1/2/25 17:40, Eli Zaretskii wrote:
>>>> Date: Sun, 29 Dec 2024 14:54:36 +0200
>>>> From: Eli Zaretskii <eliz@gnu.org>
>>>> Cc: gdb-patches@sourceware.org
>>>>
>>>> 2. Compilation error in event-top.c:
>>>>
>>>>
>>>>         CXX    event-top.o
>>>>       In file included from d:\usr\include\winsock2.h:69,
>>>> 		      from ./../gdbsupport/gdb_select.h:30,
>>>> 		      from event-top.c:43:
>>>>       event-top.c: In function 'fd_set* fd_copy(fd_set*, const fd_set*, int)':
>>>>       event-top.c:1279:22: error: invalid conversion from 'const fd_set*' to 'fd_set*' [-fpermissive]
>>>>        1279 |     if (FD_ISSET (i, src))
>>>> 	   |                      ^
>>>> 	   |                      |
>>>> 	   |                      const fd_set*
>>>>       d:\usr\include\winsock.h:164:50: note:   initializing argument 2 of 'int __FD_ISSET(SOCKET, fd_set*)'
>>>>         164 | __CRT_ALIAS int __FD_ISSET( SOCKET __fd, fd_set *__set )
>>>> 	   |                                          ~~~~~~~~^~~~~
>>>>
>>>> I solved it with an explicit cast, like this:
>>>>
>>>> --- gdb/event-top.c~0	2024-12-29 04:50:07.000000000 +0200
>>>> +++ gdb/event-top.c	2024-12-29 12:33:48.356713700 +0200
>>>> @@ -1276,7 +1276,7 @@ fd_copy (fd_set *dst, const fd_set *src,
>>>>   {
>>>>     FD_ZERO (dst);
>>>>     for (int i = 0; i < n; ++i)
>>>> -    if (FD_ISSET (i, src))
>>>> +    if (FD_ISSET (i, (fd_set *)src))
>>>>         FD_SET (i, dst);
>>>>   
>>>>     return dst;
>>>>
>>>> But I don't know if this will produce problems for other
>>>> implementations of FD_ISSET.
>>>
>>> No one responded to this part.  Is it okay to fix this, or would
>>> someone please try this first on other platforms?
>>>
>>
>> I gave this a try on aarch64-linux and it builds fine. I see no changes to the
>> testsuite.
>>
>>>> 4. Running "maint selftest" finds one failure:
>>>>
>>>>    Running selftest help_doc_invariants.
>>>>    help doc broken invariant: command 'signal-event' help doc has over-long line
>>>>    Self test failed: self-test failed at unittests/command-def-selftests.c:121
>>>>
>>>> I fixed that with the following trivial change:
>>>>
>>>> --- gdb/windows-nat.c~0	2024-12-29 04:50:07.000000000 +0200
>>>> +++ gdb/windows-nat.c	2024-12-29 12:54:32.346946000 +0200
>>>> @@ -3114,9 +3114,9 @@ _initialize_windows_nat ()
>>>>   
>>>>     add_com ("signal-event", class_run, signal_event_command, _("\
>>>>   Signal a crashed process with event ID, to allow its debugging.\n\
>>>> -This command is needed in support of setting up GDB as JIT debugger on \
>>>> -MS-Windows.  The command should be invoked from the GDB command line using \
>>>> -the '-ex' command-line option.  The ID of the event that blocks the \
>>>> +This command is needed in support of setting up GDB as JIT debugger on\n\
>>>> +MS-Windows.  The command should be invoked from the GDB command line using\n\
>>>> +the '-ex' command-line option.  The ID of the event that blocks the\n\
>>>>   crashed process will be supplied by the Windows JIT debugging mechanism."));
>>>>   
>>>>   #ifdef __CYGWIN__
>>>
>>> And what about this one? okay to commit?
>>
>> This looks OK to me, as it is a simple formatting fix for the text. Feel free to
>> push to master and the 16 branch.
>>
>> Approved-By: Luis Machado <luis.machado@arm.com>
> 
> Thanks, I've now installed both changes on the master branch and then
> cherry-picked them to gdb-16-branch.

Hi Eli,

thanks for fixing this.

I suspect that this should be done using a const_cast though, I've 
submitted a  follow-up patch implementing that ( 
https://sourceware.org/pipermail/gdb-patches/2025-January/214463.html ).

Thanks,
- Tom