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.
next prev parent 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