Re: 64bit startup
Luca, le sam. 06 janv. 2024 00:42:35 +0100, a ecrit: > Il 05/01/24 19:12, Sergey Bugaev ha scritto: > > /servers/crash-dump-core crashes on the memset () call in > > hurd:exec/elfcore.c:fetch_thread_fpregset (); the (*fpregs) pointer is > > NULL. The caller passes fpregs = ¬e.data.pr_fpreg, where note.data > > is of type struct elf_lwpstatus, defined in hurd:include/sys/procfs.h, > > whose pr_fpreg field is of type prfpregset_t, which is a typedef to > > fpregset_t, which was an actual struct on i386, but is a pointer on > > x86_64. This would've been easier to debug if I had debuginfo :) > > I had this small patch applied that apparently is enough for me to have some > kind of core dump, I'm not sure if it's a good solution: You probably rather want to fix fetch_thread_fpregset, so as to properly put the floating state into pr_fpreg. This probably needs to actually copy over explicit fields, but that's what we need anyway. > diff --git a/exec/elfcore.c b/exec/elfcore.c > index c6aa2bc8b..405fa8e0c 100644 > --- a/exec/elfcore.c > +++ b/exec/elfcore.c > @@ -544,6 +544,11 @@ dump_core (task_t task, file_t file, off_t corelimit, >note.data.pr_info.si_code = sigcode; >note.data.pr_info.si_errno = sigerror; > > +#ifdef __x86_64__ > + struct _libc_fpstate fpstate; > + memset(&fpstate, 0, sizeof(fpstate)); > + note.data.pr_fpreg = &fpstate; > +#endif >fetch_thread_regset (threads[i], ¬e.data.pr_reg); >fetch_thread_fpregset (threads[i], ¬e.data.pr_fpreg); > > > HTH > Luca
Re: 64bit startup
Il 04/01/24 10:55, Sergey Bugaev ha scritto: P.S. I have posted all of my patches, so if you're interested in hacking on aarch64-gnu Mach, you should be able to build the full toolchain now. sure, I've started looking into it, but it will take a while before I can run something in userspace. I'm working on top of your gnumach patch for now. Luca
Re: 64bit startup
Il 05/01/24 19:12, Sergey Bugaev ha scritto: /servers/crash-dump-core crashes on the memset () call in hurd:exec/elfcore.c:fetch_thread_fpregset (); the (*fpregs) pointer is NULL. The caller passes fpregs = ¬e.data.pr_fpreg, where note.data is of type struct elf_lwpstatus, defined in hurd:include/sys/procfs.h, whose pr_fpreg field is of type prfpregset_t, which is a typedef to fpregset_t, which was an actual struct on i386, but is a pointer on x86_64. This would've been easier to debug if I had debuginfo :) I had this small patch applied that apparently is enough for me to have some kind of core dump, I'm not sure if it's a good solution: diff --git a/exec/elfcore.c b/exec/elfcore.c index c6aa2bc8b..405fa8e0c 100644 --- a/exec/elfcore.c +++ b/exec/elfcore.c @@ -544,6 +544,11 @@ dump_core (task_t task, file_t file, off_t corelimit, note.data.pr_info.si_code = sigcode; note.data.pr_info.si_errno = sigerror; +#ifdef __x86_64__ + struct _libc_fpstate fpstate; + memset(&fpstate, 0, sizeof(fpstate)); + note.data.pr_fpreg = &fpstate; +#endif fetch_thread_regset (threads[i], ¬e.data.pr_reg); fetch_thread_fpregset (threads[i], ¬e.data.pr_fpreg); HTH Luca
Re: [PATCH binutils] Add support for the aarch64-gnu target (GNU/Hurd on AArch64)
Hello, Nick Clifton, le ven. 05 janv. 2024 15:35:24 +, a ecrit: > Hi Sergey, > > > Also recognized are aarch64-*-gnu tagrets, e.g. aarch64-pc-gnu or > > aarch64-unknown-gnu. > > > > The ld/emulparams/aarch64gnu.sh file is (for now) identical to > > aarch64fbsd.sh, > > or to aarch64linux.sh with Linux-specific logic removed; and mainly > > different > > from the generic aarch64elf.sh in that it does not set EMBEDDED=yes. > > > > Coupled with a corresponding GCC patch, this produces a toolchain that can > > sucessfully build working binaries targeting aarch64-gnu. > Approved - please apply. We don't have commit access, please commit it, thanks ;) Samuel
Re: 64bit startup
Sergey Bugaev, le ven. 05 janv. 2024 21:12:48 +0300, a ecrit: > Also I can't help but notice that the hurd package (i.e the translator > binaries) is still not being built as PIE, This is not actually specific to 64bit. This was set explicitly in 2016 in debian/rules, tests welcome to check whether building the package without it works now. Samuel
Re: 64bit startup
Sergey Bugaev, le ven. 05 janv. 2024 21:12:48 +0300, a ecrit: > I'm not seeing hurd-dbg / hurd-libs-dbg packages in your repo. Yes, my repo is built from the rebootstrap scripts, which drop debug etc. only for creating a booting system. For proper packages, use the usual deb.debian.org debian-ports mirror. Samuel
Re: 64bit startup
I'm not seeing hurd-dbg / hurd-libs-dbg packages in your repo. Could you please either teach me where to look, or if they're indeed missing, upload them? Also I can't help but notice that the hurd package (i.e the translator binaries) is still not being built as PIE, unlike basically all the other binaries. This actually helps with debugging for now, but please remember to ensure it does end up as PIE when the system is ready for broader use. /servers/crash-dump-core crashes on the memset () call in hurd:exec/elfcore.c:fetch_thread_fpregset (); the (*fpregs) pointer is NULL. The caller passes fpregs = ¬e.data.pr_fpreg, where note.data is of type struct elf_lwpstatus, defined in hurd:include/sys/procfs.h, whose pr_fpreg field is of type prfpregset_t, which is a typedef to fpregset_t, which was an actual struct on i386, but is a pointer on x86_64. This would've been easier to debug if I had debuginfo :) Sergey
Re: [PATCH binutils] Add support for the aarch64-gnu target (GNU/Hurd on AArch64)
Hi Sergey, Also recognized are aarch64-*-gnu tagrets, e.g. aarch64-pc-gnu or aarch64-unknown-gnu. The ld/emulparams/aarch64gnu.sh file is (for now) identical to aarch64fbsd.sh, or to aarch64linux.sh with Linux-specific logic removed; and mainly different from the generic aarch64elf.sh in that it does not set EMBEDDED=yes. Coupled with a corresponding GCC patch, this produces a toolchain that can sucessfully build working binaries targeting aarch64-gnu. Approved - please apply. Cheers Nick
Re: 64bit startup
Samuel Thibault, le jeu. 04 janv. 2024 08:57:51 +0100, a ecrit: > Sergey Bugaev, le mer. 03 janv. 2024 21:56:54 +0300, a ecrit: > > perhaps I need to try two of them in parallel and some I/O-heavy > > workload in the background, as you're saying. > > Yes, that's needed to raise the probability of the bug. > > > Could it be that the two strings are actually different (something > > being wrong with pipes perhaps)? > > I tried > > A=a ; time while /usr/bin/\[ "$A" = a ] ; do A="$(echo -n `echo a` )" ; done > ; echo $A > > The output is empty. But yes, that could be some missing flush or such > in pipes. It happens with dash too. Samuel
Re: TODO-list
Sergey Bugaev, le ven. 05 janv. 2024 13:12:02 +0300, a ecrit: > On Fri, Jan 5, 2024 at 2:09 AM Samuel Thibault > wrote: > > This is a TODO-list of mostly not-sexy things, but that we do want to > > work on, because at some point it can be a question of survival of the > > whole Hurd ecosystem (e.g. y2038 really is a concern). > > You may want to add moving off ext2 to something more modern that can > store post-2038 timestamps to the list. It doesn't need to be that radical: ext2's dynamic_rev is enough to have variable-size inodes, and thus the extended time fields. But indeed, that's a critical thing for 2038. Samuel
Re: TODO-list
On Fri, Jan 5, 2024 at 2:09 AM Samuel Thibault wrote: > This is a TODO-list of mostly not-sexy things, but that we do want to > work on, because at some point it can be a question of survival of the > whole Hurd ecosystem (e.g. y2038 really is a concern). You may want to add moving off ext2 to something more modern that can store post-2038 timestamps to the list. Sergey
Re: build bash-5.2.21 on debian-hurd-x86_64
Hello, gfleury, le ven. 05 janv. 2024 10:02:30 +0200, a ecrit: > with this small patch i managed to build it and seems to get rid of some weird > character before prompt '?2004lroot@hurd:~#' > > > --- lib/readline/terminal.c 2024-01-05 09:36:25.394494448 +0200 > +++ lib/readline/terminal.c 2024-01-05 09:36:57.022494473 +0200 > @@ -102,7 +102,7 @@ > > static int tcap_initialized; > > -#if !defined (__linux__) && !defined (NCURSES_VERSION) > +#if !defined (__linux__) && !defined (__GNU__) && !defined (NCURSES_VERSION) > # if defined (__EMX__) || defined (NEED_EXTERN_PC) > extern > # endif /* __EMX__ || NEED_EXTERN_PC */ Please forward it to the readline upstream so it can get integrated on the long run. Samuel
Re: 64bit startup
Sergey Bugaev, le ven. 05 janv. 2024 12:06:13 +0300, a ecrit: > > I use > > > > while true ; do apt install --reinstall wdiff ; done > > That did it! I can now reliably reproduce this. > > (I assume you don't mind my box constantly banging on your repo.) It's people.debian.org, it's meant for this :) You can probably also pass to apt an option to keep the donwloaded .deb > > got acd :) > > In the six times that I've reproduced it so far, I got "acd" in all cases. > Hmmm. "interesting" :) Samuel
Re: 64bit startup
On Fri, Jan 5, 2024 at 12:52 AM Samuel Thibault wrote: > Which kind of activity? I just had a loop spawning /bin/true — this should've triggered it assuming it was related to some state getting corrupted on context-switching. > I use > > while true ; do apt install --reinstall wdiff ; done That did it! I can now reliably reproduce this. (I assume you don't mind my box constantly banging on your repo.) > got acd :) In the six times that I've reproduced it so far, I got "acd" in all cases. Hmmm. Sergey
build bash-5.2.21 on debian-hurd-x86_64
Hello, I copy bash-5.2.21 source to build it on debian hurd x86_64 and it failed with - gcc -L./builtins -L./lib/readline -L./lib/readline -L./lib/glob -L./lib/tilde -L./lib/malloc -L./lib/sh -L./lib/termcap -g -O2 -o bash shell.o eval.o y.tab.o general.o make_cmd.o print_cmd.o dispose_cmd.o execute_cmd.o variables.o copy_cmd.o error.o expr.o flags.o jobs.o subst.o hashcmd.o hashlib.o mailcheck.o trap.o input.o unwind_prot.o pathexp.o sig.o test.o version.o alias.o array.o arrayfunc.o assoc.o braces.o bracecomp.o bashhist.o bashline.o list.o stringlib.o locale.o findcmd.o redir.o pcomplete.o pcomplib.o syntax.o xmalloc.o -lbuiltins -lglob -lsh -lreadline -lhistory ./lib/termcap/libtermcap.a -ltilde -lmalloc-ldl /usr/bin/ld: ./lib/termcap/libtermcap.a(termcap.o):/home/gfleury/bash-5.2.21/build/lib/termcap/../../../lib/termcap/termcap.c:298: multiple definition of `PC'; ./lib/readline/libreadline.a(terminal.o):/home/gfleury/bash-5.2.21/build/lib/readline/../../../lib/readline/terminal.c:109: first defined here /usr/bin/ld: ./lib/termcap/libtermcap.a(tparam.o):/home/gfleury/bash-5.2.21/build/lib/termcap/../../../lib/termcap/tparam.c:126: multiple definition of `BC'; ./lib/readline/libreadline.a(terminal.o):/home/gfleury/bash-5.2.21/build/lib/readline/../../../lib/readline/terminal.c:109: first defined here /usr/bin/ld: ./lib/termcap/libtermcap.a(tparam.o):/home/gfleury/bash-5.2.21/build/lib/termcap/../../../lib/termcap/tparam.c:127: multiple definition of `UP'; ./lib/readline/libreadline.a(terminal.o):/home/gfleury/bash-5.2.21/build/lib/readline/../../../lib/readline/terminal.c:109: first defined here /usr/bin/ld: ./lib/sh/libsh.a(tmpfile.o): in function `sh_mktmpname': /home/gfleury/bash-5.2.21/build/lib/sh/../../../lib/sh/tmpfile.c:160:(.text+0x17f): warning: the use of `mktemp' is dangerous, better use `mkstemp' or `mkdtemp' collect2: error: ld returned 1 exit status make: *** [Makefile:595: bash] Error 1 --- with this small patch i managed to build it and seems to get rid of some weird character before prompt '?2004lroot@hurd:~#' --- lib/readline/terminal.c 2024-01-05 09:36:25.394494448 +0200 +++ lib/readline/terminal.c 2024-01-05 09:36:57.022494473 +0200 @@ -102,7 +102,7 @@ static int tcap_initialized; -#if !defined (__linux__) && !defined (NCURSES_VERSION) +#if !defined (__linux__) && !defined (__GNU__) && !defined (NCURSES_VERSION) # if defined (__EMX__) || defined (NEED_EXTERN_PC) extern # endif /* __EMX__ || NEED_EXTERN_PC */