Re: 64bit startup

2024-01-05 Thread Samuel Thibault
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

2024-01-05 Thread Luca

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

2024-01-05 Thread Luca

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)

2024-01-05 Thread Samuel Thibault
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

2024-01-05 Thread Samuel Thibault
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

2024-01-05 Thread Samuel Thibault
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

2024-01-05 Thread Sergey Bugaev
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)

2024-01-05 Thread Nick Clifton

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

2024-01-05 Thread Samuel Thibault
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

2024-01-05 Thread Samuel Thibault
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

2024-01-05 Thread Sergey Bugaev
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

2024-01-05 Thread Samuel Thibault
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

2024-01-05 Thread Samuel Thibault
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

2024-01-05 Thread Sergey Bugaev
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

2024-01-05 Thread gfleury

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 */