Re: GDB 16.0.90 available for testing

[Eli Zaretskii <eliz@gnu.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

> > 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.