Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org
Subject: Re: GDB 16.0.90 available for testing
Date: Sun, 29 Dec 2024 14:54:36 +0200	[thread overview]
Message-ID: <868qryr6nn.fsf@gnu.org> (raw)
In-Reply-To: <20241229033130.D7F7F803EA@takamaka.gnat.com> (message from Joel Brobecker on Sun, 29 Dec 2024 07:31:30 +0400 (+04))

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

  reply	other threads:[~2024-12-29 12:55 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-29  3:31 Joel Brobecker
2024-12-29 12:54 ` Eli Zaretskii [this message]
2024-12-29 15:11   ` Hannes Domani
2024-12-29 15:33     ` Eli Zaretskii
2025-01-01 13:12       ` Eli Zaretskii
2025-01-02  1:59         ` Joel Brobecker
2025-01-02  6:12           ` Eli Zaretskii
2025-01-02  6:48             ` Joel Brobecker
2025-01-02 17:33               ` Eli Zaretskii
2025-01-02 17:38       ` Eli Zaretskii
2025-01-03  4:48         ` Joel Brobecker
2025-01-04 10:29           ` Eli Zaretskii
2025-01-02 17:40   ` Eli Zaretskii
2025-01-03 10:05     ` Luis Machado
2025-01-04 10:30       ` Eli Zaretskii
2025-01-04 11:00         ` Tom de Vries

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=868qryr6nn.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox