Re: GDB 16.0.90 available for testing

[Hannes Domani <ssbssa@yahoo.de>]

 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