Hi!
I'm trying to build gdb-15.2 for the 64bit Hurd using this patch
<https://lists.gnu.org/archive/html/bug-hurd/2024-07/msg00001.html>
Some context: Although the Guix 64bit Hurd now boots (yay!), a
statically linked tar hangs when invoked with "--mtime=@1", something
that's pretty essential to Guix builds (the dynamically linked version
runs fine, but we can only use that after the bootstrap stage). I ran
tar with parse_datetime debugging and instrumented some of tar with
printf, but was getting boring.
I tried cutting a corner and using a pre-built gdb, but apt-get update,
apt-get install gdb says:
--8<---------------cut here---------------start------------->8---
gdb is already the newest version (13.2-1+hurd.3)
--8<---------------cut here---------------end--------------->8---
Anyway, we need gdb in Guix too, so back to building gdb. Because some
gdb headers now include c++ headers like <cstdlib>, I had to use this
--8<---------------cut here---------------start------------->8---
diff --git a/gdb/config/i386/x86-gnu.mn b/gdb/config/i386/x86-gnu.mn
index b7414e3bcb4..09c5d6cfda0 100644
--- a/gdb/config/i386/x86-gnu.mn
+++ b/gdb/config/i386/x86-gnu.mn
@@ -21,7 +21,7 @@ MIGCOM = $(MIG) -cc cat - /dev/null
| $(MIGCOM) -sheader /dev/null -server /dev/null -user $*_U.c -header
$*_U.h
# MIG stubs are not yet ready for C++ compilation.
-%_S.o %_U.o : COMPILE.post += -x c -include gnu-nat-mig.h
+%_S.o %_U.o : COMPILE.post += -include gnu-nat-mig.h
NAT_GENERATED_FILES = notify_S.h notify_S.c \
process_reply_S.h process_reply_S.c \
--8<---------------cut here---------------end--------------->8---
to get the MIG stubs to generate. Then it turns out that MIG is
still generating 32bit versions of the stubs:
--8<---------------cut here---------------start------------->8---
18:03:35 janneke@dundal:/tmp/guix-build-gdb-minimal-15.2.drv-0/build/gdb
$ make V=2 exc_request_U.o
x86_64-pc-gnu-gcc -E -x c ../../gdb-15.2/gdb/exc_request.defs \
| x86_64-pc-gnu-mig -cc cat - /dev/null -sheader /dev/null -server /dev/null
-user exc_request_U.c -header exc_request_U.h
x86_64-pc-gnu-g++ -x c++ -D_GNU_SOURCE -I. -I../../gdb-15.2/gdb
-I../../gdb-15.2/gdb/config -include ../../gdb-15.2/gdb/defs.h
-DLOCALEDIR="\"/gnu/store/hma602wj6574xapalk5jixp237vppgx2-gdb-minimal-15.2/share/locale\""
-DHAVE_CONFIG_H -I../../gdb-15.2/gdb/../include/opcode -I../bfd
-I../../gdb-15.2/gdb/../bfd -I../../gdb-15.2/gdb/../include
-I../../gdb-15.2/gdb/../readline/readline/.. -I../../gdb-15.2/gdb/../zlib
-I../libdecnumber -I../../gdb-15.2/gdb/../libdecnumber
-I../../gdb-15.2/gdb/../gnulib/import -I../gnulib/import
-I../../gdb-15.2/gdb/.. -I.. -I../../gdb-15.2/gdb/../libbacktrace/
-I../libbacktrace/ -DTUI=1 -I../../gdb-15.2/gdb/.. -pthread -Wall
-Wpointer-arith -Wno-unused -Wunused-value -Wunused-variable -Wunused-function
-Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter
-Wunused-but-set-variable -Wno-sign-compare -Wno-error=maybe-uninitialized
-Wno-mismatched-tags -Wsuggest-override -Wimplicit-fallthrough=5
-Wduplicated-cond -Wshadow=local -Wdeprecated-copy -Wdeprecated-copy-dtor
-Wredundant-move -Wmissing-declarations -Wstrict-null-sentinel -Wformat
-Wformat-nonliteral -g -O2 -c -o exc_request_U.o -MT exc_request_U.o -MMD
-MP -MF ./.deps/exc_request_U.Tpo -include gnu-nat-mig.h exc_request_U.c
exc_request_U.c: In function ‘kern_return_t
exception_raise_request(mach_port_t, mach_port_t, mach_msg_type_name_t,
mach_port_t, mach_port_t, integer_t, integer_t, integer_t)’:
exc_request_U.c:89:9: error: designator order for field
‘mach_msg_type_t::msgt_inline’ does not match declaration order in ‘const
mach_msg_type_t’
89 | };
| ^
exc_request_U.c:90:9: error: ‘_Static_assert’ was not declared in this scope;
did you mean ‘static_assert’?
90 | _Static_assert(sizeof(mach_port_name_inlined_t) == 8 * 1,
"expected mach_port_name_inlined_t to be size 8 * 1");
| ^~~~~~~~~~~~~~
| static_assert
--8<---------------cut here---------------end--------------->8---
After looking at the definition of mach_msg_type_t in mach/message.h I
started patching them by hand
--8<---------------cut here---------------start------------->8---
--- build/gdb/exc_request_S.c.orig 2024-11-14 14:58:29.076500660 +0100
+++ build/gdb/exc_request_S.c 2024-11-14 14:58:45.692781486 +0100
@@ -78,51 +78,81 @@
const mach_msg_type_t threadCheck = {
.msgt_name = (unsigned char) MACH_MSG_TYPE_PORT_SEND,
.msgt_size = 64,
+#ifndef __LP64__
.msgt_number = 1,
+#endif
.msgt_inline = TRUE,
.msgt_longform = FALSE,
.msgt_deallocate = FALSE,
+#ifdef __LP64__
+ .msgt_number = 1,
+#else
.msgt_unused = 0
+#endif
};
--8<---------------cut here---------------end--------------->8---
and I made a few files compile...but it turned out more than just a
couple of small files and it doesn't seem the right thing to do.
Wondering why MIG would build 32bit stubs, I stumbled on line in MIG's
"global.h"
--8<---------------cut here---------------start------------->8---
#define IS_64BIT_ABI (desired_complex_alignof == 8)
--8<---------------cut here---------------end--------------->8---
which seemed a bit tricksy to me because "desired_complex_alignof" is
defined in "cpu.h", and "cpu.h" is not being included by "global.h". So
I added debugging to MIG too to verify that it is running in 64bit mode,
but that seems to be the case. You just have to be very sure to only
use IS_64BIT_ABI after you included "cpu.h".
So yeah, I'm kind of stuck right now. I'm working on the hurd-team
branch here:
<https://git.savannah.gnu.org/cgit/guix.git/log/?h=hurd-team>, which
uses the latest set of tags:
gnumach 1.8+git20240714
mig 1.8+git20231217
hurd 0.9.git20240714
and
glibc 2.39 (with 5 generic/i586 hurd patches we've been carrying)
gcc 14.2
Thoughts?
Greetings,
Janneke
--
Janneke Nieuwenhuizen <jann...@gnu.org> | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
