Re: GDB 16.0.90 available for testing

[Eli Zaretskii <eliz@gnu.org>]

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