Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

[Samuel Thibault]

Sergey Bugaev, le lun. 15 mai 2023 20:51:54 +0300, a ecrit:
> store (= rumpdisk, not ramdisk) and nano? :)

FI nano is now available as debian-amd64 package since a few days :)

Samuel

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

[Guy-Fleury Iteriteka]

On May 15, 2023 7:51:54 PM GMT+02:00, Sergey Bugaev  wrote:
>On Mon, May 15, 2023 at 7:28 PM Guy-Fleury Iteriteka
> wrote:
>> Yes, i know that. I fallow you on mastodon.
>
>Then you get to see all the shitposts :D
>
All posts yes :)
>> Also as you are good in writing you can documents how you created and launch 
>> it  but when you finished your great work
>
>Ah, :blush: thank you for your kind words... I don't think I'm that good,

I can tell you are really good especially with your analyse of code flow
>
>but I would surely love to write a blog post about the x86_64 port on
>the official blog, along with everyone else who's involved in the port
>(I'm certainly not the only one, and I don't mean to imply that I am).
>Let's maybe do this once the system can run a persistent writable
>store (= rumpdisk, not ramdisk) and nano? :)
Yeah that will be great
>
>Sergey

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

[Sergey Bugaev]

On Mon, May 15, 2023 at 7:28 PM Guy-Fleury Iteriteka
 wrote:
> Yes, i know that. I fallow you on mastodon.

Then you get to see all the shitposts :D

> Also as you are good in writing you can documents how you created and launch 
> it  but when you finished your great work

Ah, :blush: thank you for your kind words... I don't think I'm that good,

but I would surely love to write a blog post about the x86_64 port on
the official blog, along with everyone else who's involved in the port
(I'm certainly not the only one, and I don't mean to imply that I am).
Let's maybe do this once the system can run a persistent writable
store (= rumpdisk, not ramdisk) and nano? :)

Sergey

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

[Guy-Fleury Iteriteka]

On May 15, 2023 6:45:40 PM GMT+02:00, Samuel Thibault  
wrote:
>Guy-Fleury Iteriteka, le lun. 15 mai 2023 18:28:36 +0200, a ecrit:
>> It should be interesting to use flavio's script.
>
>I don't think Flavio aims to bootstrap various libraries and whatnot :)
>
I meant to test just the hurd core would be perhaps easy
>Samuel
>

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

[Joshua Branson]

Sergey Bugaev  writes:

> On Mon, May 15, 2023 at 6:12 PM Guy-Fleury Iteriteka
>  wrote:
>> On May 15, 2023 4:38:34 PM GMT+02:00, "jbra...@dismail.de"
>>  wrote:
>> >+As of May 2023, the Hurd developers have a bootable 64-bit Debian
>> Are sure a debian hurd boot??
>
> I'm rather sure some patches required to get anything serious (e.g.
> ext2fs) booting and working still only exist on my tablet, so this
> must be talking about me.
>
> What I have here is not really a bootable Debian... it's a Frankenhurd
> made partly out of Samuel's debs, partly built myself. There's not
> much of a system, there are the Hurd servers, libraries, and /bin/sh
> (and some utilities I'm calling from it like uname). This is in many
> ways like booting Linux with init=/bin/sh, surely you wouldn't call
> that 'booting Debian'?
>
> A more correct description would be:
>
> Work on the x8_64 userland port started in Feb 2023 [note: I'm
> counting from my first x86_64 glibc patches, but surely there's been
> related work before, e.g. Flavio's MIG changes]. As of May 2023, the
> x86_64 port works well enough to start all the essential Hurd servers
> and run /bin/sh.

Ok thanks.  I'll reword that to something that we can add to the wiki.

>
> (If you want more specific dates: I first got ld.so and libc.so
> building on March 11th, the bootstrap task first ran all the way to
> main on April 20th, and I got /bin/sh running on May12th).
>
> Sergey
>

-- 

Joshua Branson
Sent from the Hurd

Re: [PATCH 1/4] hurd: Fix aligning signal stack pointer

[Adhemerval Zanella Netto]

On 15/05/23 13:27, Samuel Thibault via Libc-alpha wrote:
> Applied, thanks!
> 
> Sergey Bugaev via Libc-alpha, le lun. 15 mai 2023 11:33:20 +0300, a ecrit:
>> Fixes 60f9bf974694d50daf58d46347b06a5975ac5ddd
>> "hurd: Port trampoline.c to x86_64"
>>
>> Checked on x86_64-gnu.
>>
>> Reported-by: Bruno Haible 
>> Signed-off-by: Sergey Bugaev 
>> ---
>>  sysdeps/mach/hurd/x86/trampoline.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/sysdeps/mach/hurd/x86/trampoline.c 
>> b/sysdeps/mach/hurd/x86/trampoline.c
>> index e13c5d85..19bddad8 100644
>> --- a/sysdeps/mach/hurd/x86/trampoline.c
>> +++ b/sysdeps/mach/hurd/x86/trampoline.c
>> @@ -200,7 +200,7 @@ _hurd_setup_sighandler (struct hurd_sigstate *ss, const 
>> struct sigaction *action
>>/* Align SP at 16 bytes.  Coupled with the fact that sigreturn_addr is
>>   16-byte aligned within the stackframe struct, this ensures that it ends
>>   up on a 16-byte aligned address, as required by the ABI.  */
>> -  sigsp = (void *) ((uintptr_t) sigsp & 16UL);
>> +  sigsp = (void *) ((uintptr_t) sigsp & ~15UL);


Btw, we have the PTR_ALIGN_DOWN macro for this.

Re: struct sigcontext in Hurd/x86_64

[Bruno Haible]

Sergey Bugaev wrote:
> Looking at [0]: 'int code' should be 'long code', otherwise you won't
> be able to extract the full 64-bit address from it.

Good point, thanks! I've changed libsigsegv and gnulib accordingly.

> I don't know how
> this works out for the BSDs -- maybe they just don't pass the address
> in there?

On FreeBSD, the argument list (when SA_SIGINFO is not specified) is
  int sig, int code, struct sigcontext *scp, void *addr

> And also, since glibc commit d865ff74ba096d016c9b1542a4e3d305169c9e55
> (2020), the Hurd supports POSIX SA_SIGINFO / siginfo / ucontext
> interface, and the old one is considered legacy / deprecated.

Thanks; I'm adding this possibility to libsigsegv, but don't activate it
now by default, since it's only supported for relatively short time
(since glibc 2.33 and, in Debian, since glibc 2.19 AFAICS).

> You should be able to get the faulting address from si->si_addr,

Yep, that works.

> and the stack pointer from uc->uc_stack.ss_sp.

Taking it from uc->uc_mcontext.gregs[REG_RSP] works as well.

I'm a bit confused about what uc->uc_stack is meant to contain [1][2],
therefore I'm not using that.

Bruno

[1] https://pubs.opengroup.org/onlinepubs/009695399/basedefs/ucontext.h.html
[2] https://www.gnu.org/software/libc/manual/html_node/System-V-contexts.html

Re: struct sigcontext in Hurd/x86_64

[Bruno Haible]

Sergey Bugaev wrote:
> state->basic is the Mach i386_thread_state structure; the
> signal handling machinery first initializes it using thread_get_state
> ()) to describe the state that the thread had at the time it was
> interrupted. It then initializes the sigcontext based on this state
> (memcpy'ing from state->basic), and then mutates state->basic to point
> %rip to the trampoline, %rsp to sigsp, etc., and then uses this same
> state->basic structure in a thread_set_state () call to apply the new
> state, to set the thread off to run the handler. But these
> modifications never reach the struct sigcontext, which still
> represents the state of the thread when it was interrupted.

Thanks for explaining, again. I've corrected the comments in libsigsegv
and gnulib accordingly.

Bruno

Re: [bug-diffutils] bug#63333: [PATCH] Add hurd-amd64 support

[Bruno Haible]

I committed:
> 2023-05-12  Bruno Haible  
> 
>   sigsegv: Add tentative support for Hurd/x86_64.
>   Reported by Samuel Thibault .
>   * lib/sigsegv.c: Update from libsigsegv/src/fault-hurd-i386.h.

This was not sufficient. Sergey Bugaev pointed out that
  - my comments were wrong,
  - the handler's parameter list needs to include 'long code', not 'int code',
for x86_64.

This patch fixes it, in sync with libsigsegv.


2023-05-15  Bruno Haible  

sigsegv: Add tentative support for Hurd/x86_64.
Based on explanations by Sergey Bugaev .
* lib/sigsegv.c: Update from libsigsegv/src/fault-hurd-i386-old.h.

diff --git a/lib/sigsegv.c b/lib/sigsegv.c
index aadba4e060..8263d9b7bd 100644
--- a/lib/sigsegv.c
+++ b/lib/sigsegv.c
@@ -361,7 +361,7 @@ int libsigsegv_version = LIBSIGSEGV_VERSION;
 
 #if defined __GNU__ /* Hurd */
 
-# define SIGSEGV_FAULT_HANDLER_ARGLIST  int sig, int code, struct sigcontext 
*scp
+# define SIGSEGV_FAULT_HANDLER_ARGLIST  int sig, long code, struct sigcontext 
*scp
 # define SIGSEGV_FAULT_ADDRESS  (unsigned long) code
 # define SIGSEGV_FAULT_CONTEXT  scp
 
@@ -370,11 +370,29 @@ int libsigsegv_version = LIBSIGSEGV_VERSION;
 
 /* scp points to a 'struct sigcontext' (defined in
glibc/sysdeps/mach/hurd/x86_64/bits/sigcontext.h).
-   The registers, at the moment the signal occurred, get pushed on the stack
-   through gnumach/x86_64/locore.S:alltraps and then copied into the struct
-   through glibc/sysdeps/mach/hurd/x86/trampoline.c.  */
-/* sc_rsp is unused (not set by gnumach/x86_64/locore.S:alltraps).  We need
-   to use sc_ursp.  */
+   The registers, at the moment the signal occurred, get pushed on the kernel
+   stack through gnumach/x86_64/locore.S:alltraps. They are denoted by a
+   'struct i386_saved_state' (defined in gnumach/i386/i386/thread.h).
+   Upon invocation of the Mach interface function thread_get_state
+   
+   (= __thread_get_state in glibc), defined in gnumach/kern/thread.c,
+   the function thread_getstatus, defined in gnumach/i386/i386/pcb.c, copies 
the
+   register values in a different arrangement into a 'struct 
i386_thread_state',
+   defined in gnumach/i386/include/mach/i386/thread_status.h. (Different
+   arrangement: trapno, err get dropped; different order of r8...r15; also rsp
+   gets set to 0.)
+   This 'struct i386_thread_state' is actually the 'basic' part of a
+   'struct machine_thread_all_state', defined in
+   glibc/sysdeps/mach/x86/thread_state.h.
+   From there, the function _hurd_setup_sighandler, defined in
+   glibc/sysdeps/mach/hurd/x86/trampoline.c,
+   1. sets rsp to the same value as ursp,
+   2. copies the 'struct i386_thread_state' into the appropriate part of a
+  'struct sigcontext', defined in
+  glibc/sysdeps/mach/hurd/x86_64/bits/sigcontext.h.  */
+/* Both sc_rsp and sc_ursp have the same value.
+   It appears more reliable to use sc_ursp because sc_rsp is marked as
+   "not used".  */
 #  define SIGSEGV_FAULT_STACKPOINTER  scp->sc_ursp
 
 # elif defined __i386__
@@ -382,12 +400,28 @@ int libsigsegv_version = LIBSIGSEGV_VERSION;
 
 /* scp points to a 'struct sigcontext' (defined in
glibc/sysdeps/mach/hurd/i386/bits/sigcontext.h).
-   The registers, at the moment the signal occurred, get pushed on the stack
-   through gnumach/i386/i386/locore.S:alltraps and then copied into the struct
-   through glibc/sysdeps/mach/hurd/x86/trampoline.c.  */
-/* Both sc_esp and sc_uesp appear to have the same value.
-   It appears more reliable to use sc_uesp because it is labelled as
-   "old esp, if trapped from user".  */
+   The registers, at the moment the signal occurred, get pushed on the kernel
+   stack through gnumach/i386/i386/locore.S:alltraps. They are denoted by a
+   'struct i386_saved_state' (defined in gnumach/i386/i386/thread.h).
+   Upon invocation of the Mach interface function thread_get_state
+   
+   (= __thread_get_state in glibc), defined in gnumach/kern/thread.c,
+   the function thread_getstatus, defined in gnumach/i386/i386/pcb.c, copies 
the
+   register values in a different arrangement into a 'struct 
i386_thread_state',
+   defined in gnumach/i386/include/mach/i386/thread_status.h. (Different
+   arrangement: trapno, err get dropped; also esp gets set to 0.)
+   This 'struct i386_thread_state' is actually the 'basic' part of a
+   'struct machine_thread_all_state', defined in
+   glibc/sysdeps/mach/x86/thread_state.h.
+   From there, the function _hurd_setup_sighandler, defined in
+   glibc/sysdeps/mach/hurd/x86/trampoline.c,
+   1. sets esp to the same value as uesp,
+   2. copies the 'struct i386_thread_state' into the appropriate part of a
+  'struct sigcontext', defined in
+  glibc/sysdeps/mach/hurd/i386/bits/sigcontext.h.  */
+/* Both sc_esp and sc_uesp have the same value.
+   It appears more reliable to use sc_uesp 

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

[Samuel Thibault]

Sergey Bugaev, le sam. 13 mai 2023 20:45:35 +0300, a ecrit:
> On Sat, May 13, 2023 at 7:38 PM jbra...@dismail.de  wrote:
> > +Hurd developers are adding 64-bit support, and they plan to drop the
> > +32-bit support, once the 64-bit support is deemed stable.
> 
> Is this really the plan? :(

No, but I don't think we want to plan to take the effort to fix the
y2038 concern.

Samuel

Re: [PATCH] remove acpi for 64-bit debugging and acpi building doc

[Samuel Thibault]

applied, thanks!

pasha (biblio), le dim. 14 mai 2023 10:02:31 +0200, a ecrit:
> ---
>  hurd/building.mdwn  |  6 ++
>  microkernel/mach/gnumach/debugging.mdwn | 14 --
>  2 files changed, 14 insertions(+), 6 deletions(-)
> 
> diff --git a/hurd/building.mdwn b/hurd/building.mdwn
> index 7cfc7c7e..63c33498 100644
> --- a/hurd/building.mdwn
> +++ b/hurd/building.mdwn
> @@ -93,6 +93,12 @@ or `/local/`, so your current Hurd servers will be 
> replaced.
>  To install to a different location, specify `--prefix=PREFIX` as `configure`
>  parameter, e.g. `--prefix=/usr` (as done when having a real `/usr`).
>  
> +To build acpi:
> +
> +$ make acpi
> +
> +You may need to install necessary acpi headers (`libacpica-dev` package in 
> Debian based distro).
> +
>  By default profiling versions of all the libraries and code are generated but
>  this is useless in most of the cases, so we disable them by specifying
>  `--disable-profile` on `configure`'s command line.
> diff --git a/microkernel/mach/gnumach/debugging.mdwn 
> b/microkernel/mach/gnumach/debugging.mdwn
> index 0e4898be..0bf0ee79 100644
> --- a/microkernel/mach/gnumach/debugging.mdwn
> +++ b/microkernel/mach/gnumach/debugging.mdwn
> @@ -130,7 +130,10 @@ working directory. For example:
>  
>  ## Debug 64-bit gnumach
>  
> -[[build|microkernel/mach/gnumach/building/]] 64-bit gnumach
> +[[build|microkernel/mach/gnumach/building/]] 64-bit gnumach with:
> +
> +$ export CFLAGS=-g
> +$ ../configure --enable-kdb ...
>  
>  run a spare Hurd vm (prepare for data loss in vm):
>  
> @@ -151,14 +154,13 @@ example `/boot/grub/grub.cfg`:
>  
>  multiboot   /boot/gnumach-1.8-486.gz root=part:2:device:hd0 
> console=com0
>  ...
> -module  /hurd/acpi.static acpi \
> ---host-priv-port='${host-port}' 
> --device-master-port='${device-port}' \
> ---next-task='${fs-task}' \
> -'$(acpi-task=task-create)' '$(task-resume)'
> +echo'Loading the Hurd ...'
>  module  /hurd/ext2fs.static ext2fs --readonly \
>  --multiboot-command-line='${kernel-command-line}' \
> + \
> +--host-priv-port='${host-port}' 
> --device-master-port='${device-port}' \
>  --exec-server-task='${exec-task}' -T typed '${root}' \
> -'$(fs-task=task-create)'
> +'$(fs-task=task-create)' '$(task-resume)'
>  module  /lib/ld.so.1 exec /hurd/exec '$(exec-task=task-create)'
>  
>  
> -- 
> 2.30.2
> 
> 

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

[Samuel Thibault]

Guy-Fleury Iteriteka, le lun. 15 mai 2023 18:28:36 +0200, a ecrit:
> It should be interesting to use flavio's script.

I don't think Flavio aims to bootstrap various libraries and whatnot :)

Samuel

Re: [PATCH v2 4/4] Cosmetic tweaks

[Samuel Thibault]

Applied, thanks!

Sergey Bugaev, le lun. 15 mai 2023 10:36:00 +0300, a ecrit:
> ---
>  proc/msg.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/proc/msg.c b/proc/msg.c
> index 25ce0d5b..93ad995b 100644
> --- a/proc/msg.c
> +++ b/proc/msg.c
> @@ -80,7 +80,7 @@ S_proc_setmsgport (struct proc *p,
> perror ("pthread_create");
>   }
>  }
> -  
> +
>return 0;
>  }
>  
> @@ -107,7 +107,7 @@ check_msgport_death (struct proc *p)
>  {
>mach_port_type_t type;
>error_t err;
> -  
> +
>err = mach_port_type (mach_task_self (), p->p_msgport, );
>if (err || (type & MACH_PORT_TYPE_DEAD_NAME))
>   {
> -- 
> 2.40.1
> 
> 

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.

Re: [PATCH v2 3/4] proc: Don't buffer Mach console output

[Samuel Thibault]

Applied, thanks!

Sergey Bugaev, le lun. 15 mai 2023 10:35:59 +0300, a ecrit:
> Normally glibc does not buffer tty output, but a devstream backed by
> the Mach console device cannot be isatty'ed. So we need to ask glibc
> explicitly to not buffer it. This is what the startup and mach-defpager
> do already.
> ---
>  proc/main.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/proc/main.c b/proc/main.c
> index 8a2dc9ff..747646ef 100644
> --- a/proc/main.c
> +++ b/proc/main.c
> @@ -132,6 +132,7 @@ open_console (mach_port_t device_master)
>  
>stdin = mach_open_devstream (cons, "r");
>stdout = stderr = mach_open_devstream (cons, "w");
> +  setbuf (stdout, NULL);
>  
>got_console = 1;
>mach_port_deallocate (mach_task_self (), cons);
> -- 
> 2.40.1
> 
> 

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.

Re: [PATCH v2 2/4] proc: Report CPU_TYPE_X86_64 in uname as "x86_64"

[Samuel Thibault]

This was already fixed :)

Sergey Bugaev, le lun. 15 mai 2023 10:35:58 +0300, a ecrit:
> This fixes a proc server crash during startup inside
> initialize_version_info ().
> ---
>  proc/cpu-types.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/proc/cpu-types.c b/proc/cpu-types.c
> index 3d89d5a7..89787d3d 100644
> --- a/proc/cpu-types.c
> +++ b/proc/cpu-types.c
> @@ -30,6 +30,9 @@ const char *const mach_cpu_types[] =
>  #ifdef CPU_TYPE_PENTIUMPRO
>  [CPU_TYPE_PENTIUMPRO] = "i686",
>  #endif
> +#ifdef CPU_TYPE_X86_64
> +[CPU_TYPE_X86_64] = "x86_64",
> +#endif
>  #ifdef CPU_TYPE_POWERPC
>  [CPU_TYPE_POWERPC] = "powerpc",
>  #endif
> -- 
> 2.40.1
> 
> 

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.

Re: [PATCH v2 1/4] exec: Allow loading x86_64 executables on x86_64

[Samuel Thibault]

Applied, thanks!

Sergey Bugaev, le lun. 15 mai 2023 10:35:57 +0300, a ecrit:
> Since we don't support mixing i386 and x86_64 binaries on the same
> system (as running them requires different build-time gnumach
> configurations), the exec server can simply require the binary being
> loaded to have been built for the same architecture as the exec server
> itself.
> ---
>  exec/exec.c | 8 +++-
>  exec/hostarch.c | 9 +
>  2 files changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/exec/exec.c b/exec/exec.c
> index 8944167d..2e5fbfcd 100644
> --- a/exec/exec.c
> +++ b/exec/exec.c
> @@ -518,6 +518,12 @@ prepare (file_t file, struct execdata *e)
>  #define host_ELFDATA ELFDATA2LSB
>  #endif
>  
> +#ifdef __LP64__
> +#define host_ELFCLASS ELFCLASS64
> +#else
> +#define host_ELFCLASS ELFCLASS32
> +#endif
> +
>  static void
>  check_elf (struct execdata *e)
>  {
> @@ -539,7 +545,7 @@ check_elf (struct execdata *e)
>return;
>  }
>  
> -  if (ehdr->e_ident[EI_CLASS] != ELFCLASS32 ||
> +  if (ehdr->e_ident[EI_CLASS] != host_ELFCLASS ||
>ehdr->e_ident[EI_DATA] != host_ELFDATA ||
>ehdr->e_ident[EI_VERSION] != EV_CURRENT ||
>ehdr->e_version != EV_CURRENT ||
> diff --git a/exec/hostarch.c b/exec/hostarch.c
> index 363fda69..ed50e0a8 100644
> --- a/exec/hostarch.c
> +++ b/exec/hostarch.c
> @@ -72,6 +72,15 @@ elf_machine_matches_host (ElfW(Half) e_machine)
>  case CPU_TYPE_PENTIUMPRO:
>CACHE (e_machine == EM_386);
>  
> +/* When building for x86_64, CPU_TYPE_X86_64 must be defined; otherwise
> +   it's OK if we don't compile this branch -- none of the branches other
> +   than the actual architecture the code is built for are going to be
> +   taken anyway.  */
> +#if defined (CPU_TYPE_X86_64) || defined (__x86_64__)
> +case CPU_TYPE_X86_64:
> +  CACHE (e_machine == EM_X86_64);
> +#endif
> +
>  case CPU_TYPE_POWERPC:
>CACHE (e_machine == EM_PPC);
>  
> -- 
> 2.40.1
> 
> 

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.

Re: [PATCH] x86_64: Fix reporting fsgs base in thread_get_state ()

[Samuel Thibault]

Applied, thanks!

Sergey Bugaev, le lun. 15 mai 2023 10:44:34 +0300, a ecrit:
> Fixes 31dd30a94a682955c3c9e2f42252b4a07687067a "add setting gs/fsbase".
> ---
> This was breaking fork () in glibc when it tried to set up TLS in the
> new process by copying fs_base from an existing thread.
> 
>  i386/i386/pcb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/i386/i386/pcb.c b/i386/i386/pcb.c
> index a5efb9a8..fb535709 100644
> --- a/i386/i386/pcb.c
> +++ b/i386/i386/pcb.c
> @@ -873,7 +873,7 @@ kern_return_t thread_getstatus(
>  
>  state = (struct i386_fsgs_base_state *) tstate;
>  state->fs_base = thread->pcb->iss.fsbase;
> -state->fs_base = thread->pcb->iss.gsbase;
> +state->gs_base = thread->pcb->iss.gsbase;
>  *count = i386_FSGS_BASE_STATE_COUNT;
>  break;
>  }
> -- 
> 2.40.1
> 
> 

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.

Re: [PATCH 4/4] hurd: Fix computing user stack pointer

[Samuel Thibault]

Applied, thanks!

Sergey Bugaev, le lun. 15 mai 2023 11:33:23 +0300, a ecrit:
> Fixes b574ae0a2876ee94e4fe617f878407bf818c2df0
> "hurd: Implement sigreturn for x86_64"
> 
> Checked on x86_64-gnu.
> 
> Signed-off-by: Sergey Bugaev 
> ---
>  sysdeps/mach/hurd/x86_64/sigreturn.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sysdeps/mach/hurd/x86_64/sigreturn.c 
> b/sysdeps/mach/hurd/x86_64/sigreturn.c
> index 82247e3c..5d3a4d31 100644
> --- a/sysdeps/mach/hurd/x86_64/sigreturn.c
> +++ b/sysdeps/mach/hurd/x86_64/sigreturn.c
> @@ -126,7 +126,7 @@ __sigreturn (struct sigcontext *scp)
> copy the registers onto the user's stack, switch there, pop and
> return.  */
>  
> -uintptr_t *usp = (uintptr_t *) scp->sc_ursp - 128;
> +uintptr_t *usp = (uintptr_t *) (scp->sc_ursp - 128);
>  
>  *--usp = scp->sc_rip;
>  *--usp = scp->sc_rfl;
> -- 
> 2.40.1
> 
> 

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.

Re: [PATCH 3/4] hurd: Fix sc_i386_thread_state layout

[Samuel Thibault]

Applied, thanks!

Sergey Bugaev, le lun. 15 mai 2023 11:33:22 +0300, a ecrit:
> The real i386_thread_state Mach structure has an alignment of 8 on
> x86_64. However, in struct sigcontext, the compiler was packing sc_gs
> (which is the first member of sc_i386_thread_state) into the same 8-byte
> slot as sc_error; this resulted in the rest of sc_i386_thread_state
> members having wrong offsets relative to each other, and the overall
> sc_i386_thread_state layout mismatching that of i386_thread_state.
> 
> Fix this by explicitly adding the required padding members, and
> statically asserting that this results in the desired alignment.
> 
> The same goes for sc_i386_float_state.
> 
> Checked on x86_64-gnu.
> 
> Signed-off-by: Sergey Bugaev 
> ---
>  sysdeps/mach/hurd/x86/trampoline.c | 6 ++
>  sysdeps/mach/hurd/x86_64/bits/sigcontext.h | 8 
>  2 files changed, 14 insertions(+)
> 
> diff --git a/sysdeps/mach/hurd/x86/trampoline.c 
> b/sysdeps/mach/hurd/x86/trampoline.c
> index 1f92064e..6318c952 100644
> --- a/sysdeps/mach/hurd/x86/trampoline.c
> +++ b/sysdeps/mach/hurd/x86/trampoline.c
> @@ -242,11 +242,17 @@ _hurd_setup_sighandler (struct hurd_sigstate *ss, const 
> struct sigaction *action
>  
>/* struct sigcontext is laid out so that starting at sc_gs mimics a
>struct i386_thread_state.  */
> +  _Static_assert (offsetof (struct sigcontext, sc_i386_thread_state)
> +   % __alignof__ (struct i386_thread_state) == 0,
> +   "sc_i386_thread_state layout mismatch");
>memcpy (>sc_i386_thread_state,
> >basic, sizeof (state->basic));
>  
>/* struct sigcontext is laid out so that starting at sc_fpkind mimics
>a struct i386_float_state.  */
> +  _Static_assert (offsetof (struct sigcontext, sc_i386_float_state)
> +   % __alignof__ (struct i386_float_state) == 0,
> +   "sc_i386_float_state layout mismatch");
>ok = machine_get_state (ss->thread, state, i386_FLOAT_STATE,
> >fpu, >sc_i386_float_state,
> sizeof (state->fpu));
> diff --git a/sysdeps/mach/hurd/x86_64/bits/sigcontext.h 
> b/sysdeps/mach/hurd/x86_64/bits/sigcontext.h
> index 3a3b34bc..63960544 100644
> --- a/sysdeps/mach/hurd/x86_64/bits/sigcontext.h
> +++ b/sysdeps/mach/hurd/x86_64/bits/sigcontext.h
> @@ -46,6 +46,11 @@ struct sigcontext
>  /* Error code associated with this signal (interpreted as `error_t').  */
>  int sc_error;
>  
> +/* Make sure the below members are properly aligned, and not packed
> +   together with sc_error -- otherwise the layout won't match that of
> +   i386_thread_state.  */
> +int sc_pad1;
> +
>  /* All following members are machine-dependent.  The rest of this
> structure is written to be laid out identically to:
> {
> @@ -86,6 +91,9 @@ struct sigcontext
>  long sc_ursp;/* This stack pointer is used.  */
>  int sc_ss;   /* Stack segment register.  */
>  
> +/* Make sure the below has the same layout as i386_float_state.  */
> +int sc_pad2;
> +
>  /* Following mimics struct i386_float_state.  Structures and symbolic
> values can be found in .  */
>  #define sc_i386_float_state sc_fpkind
> -- 
> 2.40.1
> 
> 

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.

Re: [PATCH 1/4] hurd: Fix aligning signal stack pointer

[Samuel Thibault]

Applied, thanks!

Sergey Bugaev via Libc-alpha, le lun. 15 mai 2023 11:33:20 +0300, a ecrit:
> Fixes 60f9bf974694d50daf58d46347b06a5975ac5ddd
> "hurd: Port trampoline.c to x86_64"
> 
> Checked on x86_64-gnu.
> 
> Reported-by: Bruno Haible 
> Signed-off-by: Sergey Bugaev 
> ---
>  sysdeps/mach/hurd/x86/trampoline.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sysdeps/mach/hurd/x86/trampoline.c 
> b/sysdeps/mach/hurd/x86/trampoline.c
> index e13c5d85..19bddad8 100644
> --- a/sysdeps/mach/hurd/x86/trampoline.c
> +++ b/sysdeps/mach/hurd/x86/trampoline.c
> @@ -200,7 +200,7 @@ _hurd_setup_sighandler (struct hurd_sigstate *ss, const 
> struct sigaction *action
>/* Align SP at 16 bytes.  Coupled with the fact that sigreturn_addr is
>   16-byte aligned within the stackframe struct, this ensures that it ends
>   up on a 16-byte aligned address, as required by the ABI.  */
> -  sigsp = (void *) ((uintptr_t) sigsp & 16UL);
> +  sigsp = (void *) ((uintptr_t) sigsp & ~15UL);
>  #endif
>  
>/* Push the arguments to call `trampoline' on the stack.  */
> -- 
> 2.40.1
> 

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

[Guy-Fleury Iteriteka]

On May 15, 2023 5:58:12 PM GMT+02:00, Sergey Bugaev  wrote:
>On Mon, May 15, 2023 at 6:12 PM Guy-Fleury Iteriteka
> wrote:
>> On May 15, 2023 4:38:34 PM GMT+02:00, "jbra...@dismail.de" 
>>  wrote:
>> >+As of May 2023, the Hurd developers have a bootable 64-bit Debian
>> Are sure a debian hurd boot??
>
>I'm rather sure some patches required to get anything serious (e.g.
>ext2fs) booting and working still only exist on my tablet, so this
>must be talking about me.
>
>What I have here is not really a bootable Debian... it's a Frankenhurd
>made partly out of Samuel's debs, partly built myself. There's not
>much of a system, there are the Hurd servers, libraries, and /bin/sh
>(and some utilities I'm calling from it like uname). This is in many
>ways like booting Linux with init=/bin/sh, surely you wouldn't call
>that 'booting Debian'?

Yes, i know that. I fallow you on mastodon.
It should be interesting to use flavio's script.
Also as you are good in writing you can documents how you created and launch it 
 but when you finished your great work 
>
>A more correct description would be:
>
>Work on the x8_64 userland port started in Feb 2023 [note: I'm
>counting from my first x86_64 glibc patches, but surely there's been
>related work before, e.g. Flavio's MIG changes]. As of May 2023, the
>x86_64 port works well enough to start all the essential Hurd servers
>and run /bin/sh.
>
>(If you want more specific dates: I first got ld.so and libc.so
>building on March 11th, the bootstrap task first ran all the way to
>main on April 20th, and I got /bin/sh running on May12th).
>
>Sergey
>

Re: [PATCH 2/4] hurd: Align signal stack pointer after allocating stackframe

[Samuel Thibault]

Applied, thanks!

Sergey Bugaev via Libc-alpha, le lun. 15 mai 2023 11:33:21 +0300, a ecrit:
> sizeof (*stackframe) appears to be divisible by 16, but we should not
> rely on that. So make sure to leave enough space for the stackframe
> first, and then align the final pointer at 16 bytes.
> 
> Checked on x86_64-gnu.
> 
> Signed-off-by: Sergey Bugaev 
> ---
>  sysdeps/mach/hurd/x86/trampoline.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/sysdeps/mach/hurd/x86/trampoline.c 
> b/sysdeps/mach/hurd/x86/trampoline.c
> index 19bddad8..1f92064e 100644
> --- a/sysdeps/mach/hurd/x86/trampoline.c
> +++ b/sysdeps/mach/hurd/x86/trampoline.c
> @@ -196,15 +196,14 @@ _hurd_setup_sighandler (struct hurd_sigstate *ss, const 
> struct sigaction *action
>  #endif
>  }
>  
> +  /* Push the arguments to call `trampoline' on the stack.  */
> +  sigsp -= sizeof (*stackframe);
>  #ifdef __x86_64__
>/* Align SP at 16 bytes.  Coupled with the fact that sigreturn_addr is
>   16-byte aligned within the stackframe struct, this ensures that it ends
>   up on a 16-byte aligned address, as required by the ABI.  */
>sigsp = (void *) ((uintptr_t) sigsp & ~15UL);
>  #endif
> -
> -  /* Push the arguments to call `trampoline' on the stack.  */
> -  sigsp -= sizeof (*stackframe);
>stackframe = sigsp;
>  
>if (_hurdsig_catch_memory_fault (stackframe))
> -- 
> 2.40.1
> 

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.

Re: [PATCH 1/5] open_issues/Upstart.mdwn: delete file.

[Samuel Thibault]

I applied the series, thanks!

jbra...@dismail.de, le lun. 15 mai 2023 11:34:53 -0400, a ecrit:
> ---
> We have no interest in supporting Upstart since it it a dead project.
> 
>  open_issues/Upstart.mdwn | 69 
>  1 file changed, 69 deletions(-)
>  delete mode 100644 open_issues/Upstart.mdwn
> 
> diff --git a/open_issues/Upstart.mdwn b/open_issues/Upstart.mdwn
> deleted file mode 100644
> index 1972e197..
> --- a/open_issues/Upstart.mdwn
> +++ /dev/null
> @@ -1,69 +0,0 @@
> -[[!meta copyright="Copyright © 2013, 2014 Free Software Foundation, Inc."]]
> -
> -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
> -id="license" text="Permission is granted to copy, distribute and/or modify 
> this
> -document under the terms of the GNU Free Documentation License, Version 1.2 
> or
> -any later version published by the Free Software Foundation; with no 
> Invariant
> -Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the 
> license
> -is included in the section entitled [[GNU Free Documentation
> -License|/fdl]]."]]"""]]
> -
> -
> -[[!template id=highlight text="""/!\ Obsolete /!\
> -
> 
> -
> -[[systemd|Systemd]] has almost universally replaced upstart."""]]
> -
> -Upstart is an event based init system that is GPL licensed, however upstream
> -contributions are under a CLA that permits proprietary relicensing.
> -
> -Most major GNU/Linux distributions are choosing systemd as their init system
> -instead of upstart.  The original upstart developers seem to have stopped
> -developing it.
> -
> -The following are the words of Colin Watson on the 
> debian-c...@lists.debian.org
> -mailing list and list the requirements of a potential HURD port:
> -
> ->I haven't looked at this in much detail, and I suspect Dimitri hasn't
> -yet although IIRC he did express some interest in doing so.  But I
> -haven't seen anyone else try to outline the scope of a port, so let me
> -try to do so for the sake of general understanding.  As far as I know,
> -the hardest parts would be inotify, ptrace, and prctl
> -(PR_SET_CHILD_SUBREAPER).
> -
> ->inotify is used to notice changes to configuration files.  This is
> -certainly helpful for users, but it isn't critical as "initctl
> -reload-configuration" works without it.  We could probably do without
> -this with the aid of a dpkg trigger.
> -
> ->ptrace is used for "expect fork" and "expect daemon"; as I indicated in
> -another post, I think it would be preferable to avoid these in Debian
> -and quite possibly to compile them out.  (This would mean we wouldn't be
> -able to translate Ubuntu jobs quite as directly, and a number of
> -important jobs would definitely need to be changed, but the conversion
> -isn't usually particularly difficult.)
> -
> ->prctl (PR_SET_CHILD_SUBREAPER) is used to make SIGCHLD notification work
> -properly when Upstart is supervising a user session.  This isn't a
> -required feature and could easily be compiled out until suitable kernel
> -support is available (this actually seems like the sort of thing that
> -could be done in the Hurd without too much difficulty, but I haven't
> -looked into it).  If absent, it might well impede the ability to do an
> -advanced desktop port, but it wouldn't get in the way of porting the
> -bulk of services.
> -
> ->There might also be odds and ends around the details of wait status
> -handling.
> -
> -inotify seems to be a feature that is often used in GNU/Linux programs, and
> -implementing the feature in the HURD seems like a better and more rewarding
> -option than porting the code in Upstart.
> -
> -Although many daemons double fork, that behavior seems to be dying out, and
> -one can comfortably ignore the "expect fork/daemon" functionality of Upstart
> -(and compile it out).
> -
> -[[!tag open_issue_porting]]
> -
> -See also the discussion about upstart on the [[systemd]] page.
> -- 
> 2.32.0
> 
> 

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

[Sergey Bugaev]

On Mon, May 15, 2023 at 6:12 PM Guy-Fleury Iteriteka
 wrote:
> On May 15, 2023 4:38:34 PM GMT+02:00, "jbra...@dismail.de" 
>  wrote:
> >+As of May 2023, the Hurd developers have a bootable 64-bit Debian
> Are sure a debian hurd boot??

I'm rather sure some patches required to get anything serious (e.g.
ext2fs) booting and working still only exist on my tablet, so this
must be talking about me.

What I have here is not really a bootable Debian... it's a Frankenhurd
made partly out of Samuel's debs, partly built myself. There's not
much of a system, there are the Hurd servers, libraries, and /bin/sh
(and some utilities I'm calling from it like uname). This is in many
ways like booting Linux with init=/bin/sh, surely you wouldn't call
that 'booting Debian'?

A more correct description would be:

Work on the x8_64 userland port started in Feb 2023 [note: I'm
counting from my first x86_64 glibc patches, but surely there's been
related work before, e.g. Flavio's MIG changes]. As of May 2023, the
x86_64 port works well enough to start all the essential Hurd servers
and run /bin/sh.

(If you want more specific dates: I first got ld.so and libc.so
building on March 11th, the bootstrap task first ran all the way to
main on April 20th, and I got /bin/sh running on May12th).

Sergey

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

[Joshua Branson]

Guy-Fleury Iteriteka  writes:

> On May 15, 2023 4:38:34 PM GMT+02:00, "jbra...@dismail.de"
>  wrote:
>>---
>>I explained that the Hurd has initial 64-bit support, but I 
>>did not mention if the project plans to drop 32-bit
>>support.  Joshua
>>
>> faq/64-bit.mdwn  | 10 +++---
>> open_issues/64-bit_port.mdwn |  6 +-
>> 2 files changed, 4 insertions(+), 12 deletions(-)
>>
>>diff --git a/faq/64-bit.mdwn b/faq/64-bit.mdwn
>>index 2e1278cb..82513d25 100644
>>--- a/faq/64-bit.mdwn
>>+++ b/faq/64-bit.mdwn
>>@@ -13,11 +13,7 @@ License|/fdl]]."]]"""]]
>> 
>> [[!meta title="Is there a 64-bit version?"]]
>> 
>>-There are currently no plan for 64-bit userland for the short term, but there
>>-are plans for 64-bit kernelland with 32-bit userland, which will
>> notably permit
>>-to efficiently make use of more than 2 GiB memory and provide 4 GiB userland
>>-addressing space. The kernel support was merged into GNU Mach, the currently
>>-missing bit is the 32/64 mig translation for kernel RPCs.
>>+As of May 2023, the Hurd developers have a bootable 64-bit Debian
> Are sure a debian hurd boot??

I believe so.  It is certainly not a Guix Hurd.  :)  

>>+GNU/Hurd.  The 64 bit kernel and userspace is mostly working, but bugs
>>+still need to be fixed.
>> 
>>-That being said, you can always run a 32-bit version on a 64-bit machine, it
>>-just works, processes are just limited to a couple GiB available memory.
>>diff --git a/open_issues/64-bit_port.mdwn b/open_issues/64-bit_port.mdwn
>>index 95761828..ca30ba64 100644
>>--- a/open_issues/64-bit_port.mdwn
>>+++ b/open_issues/64-bit_port.mdwn
>>@@ -13,11 +13,7 @@ License|/fdl]]."]]"""]]
>> 
>> [[!inline pages="title(Is there a 64-bit version?)" feeds="no" raw="yes"]]
>> 
>>-**What is left for initial support (32-on-64) is**
>>-
>>-  * Fixing bugs :)
>>-
>>-**For pure 64bit support, we need to**
>>+**For 64-bit support, we need to**
>> 
>>   * Fix bugs :)
>>   * bootstrap a distrib
>
> Hi,
>

-- 

Joshua Branson
Sent from the Hurd

[PATCH 4/5] open_issues/sync_but_still_unclean_filesystem.mdwn: delete file.

[jbra...@dismail.de]

---
 .../sync_but_still_unclean_filesystem.mdwn| 39 ---
 1 file changed, 39 deletions(-)
 delete mode 100644 open_issues/sync_but_still_unclean_filesystem.mdwn

diff --git a/open_issues/sync_but_still_unclean_filesystem.mdwn 
b/open_issues/sync_but_still_unclean_filesystem.mdwn
deleted file mode 100644
index eae98077..
--- a/open_issues/sync_but_still_unclean_filesystem.mdwn
+++ /dev/null
@@ -1,39 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled [[GNU Free Documentation
-License|/fdl]]."]]"""]]
-
-[[!tag open_issue_gnumach open_issue_hurd]]
-
-Also filed as [[!GNU_Savannah_bug 29292]].
-
-\#hurd, 2010, end of May / beginning of June
-
-[runnign sync, but sill unclean filesystem at next boot]
- guillem: when libpager syncs an object, it sends an m_o_lock_request
-  and waits (if the synchronous argument was specified) for a
-  m_o_lock_completed. But m_o_lock_completed only means that dirty pages
-  have been sent to the translator, and this one still needs to write them
-  to the backing storage
- guillem: there's no problem if sync() returns before actually
-  writting the changes to disk, but this also happens when shutting down
-  the translator
- guillem: in theory, locking mechanisms in libpager should prevent
-  this from happening by keeping track of write operations, but this seems
-  to fail in some situations
-
-It helps a lot to run [[`syncfs --synchronous /`|hurd/syncfs]] before issuing
-the `halt` or `reboot` command.  This will prevent most of the uncleanliness.
-Of course, [[hurd/translator/ext2fs]] is meant to be doing this to-disk
-synchronization internally upon translator shutdown, but evidently it doesn't
-in all cases.
-
-Apparently diskfs simply does not set filesystems as read-only:
-.
-
-A patch was applied, and the sync issue does not seem to happen any more.
-- 
2.32.0

[PATCH 5/5] * open_issues/automatic_backtraces_when_assertions_hit.mdwn: delete file.

[jbra...@dismail.de]

---
 ...omatic_backtraces_when_assertions_hit.mdwn | 79 ---
 1 file changed, 79 deletions(-)
 delete mode 100644 open_issues/automatic_backtraces_when_assertions_hit.mdwn

diff --git a/open_issues/automatic_backtraces_when_assertions_hit.mdwn 
b/open_issues/automatic_backtraces_when_assertions_hit.mdwn
deleted file mode 100644
index df7294e9..
--- a/open_issues/automatic_backtraces_when_assertions_hit.mdwn
+++ /dev/null
@@ -1,79 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2012 Free Software Foundation, Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled [[GNU Free Documentation
-License|/fdl]]."]]"""]]
-
-[[!tag open_issue_glibc]]
-
-
-# IRC, unknown channel, unknown date
-
- tschwinge: ext2fs.static: thread-cancel.c:55: hurd_thread_cancel: 
Assertion `! __spin_lock_locked (>critical_section_lock)' failed.
- it'd be great if we could have backtraces in such case
- at least just the function names
- and in this case (static), just addresses would be enough
-
-
-# IRC, freenode, #hurd, 2012-07-19
-
-In context of the [[ext2fs_libports_reference_counting_assertion]].
-
- pinotree: tschwinge: do you know if our packages are built with
-  -rdynamic ?
- braunr: debian's cflags don't include it, so unless the upstream
-  build systems do, -rdynamic is not added
- i doubt glibc' backtrace() is able to find debugging symbol files
-  on its own
- what do you mean?
- the port reference bug youpi noticed is rare
- even on linux, a program compiled with normal optimizations (eg
-  -O2 -g) can give just pointer values in backtrace()'s output
- core dumps are unreliable at best
-
-[[crash_server]].
-
- uh, no, backtrace does give names
- but not with -fomit-frame-pointer
- unless the binary is built with -rdynamic
- at least it used to
- not really, when being optimized some steps can be optimized
-  away (eg inlines)
- that's ok
- anyway, the point is i'd like a way that can give us as much
-  information as possible when the problem happens
- the stack trace being the most useful imo
- do you face issues currently with backtrace()?
- not tried yet
- i guess i could make the application trap in the kernel, and fault
-  there, so we can attach gdb while still in the pager address space :>
- that would imply the need for interactivity when the fault
-  happens, wouldn't it?
- no
- it would remain this way until someone comes, hours, days later
- pinotree: well ok, it would require interactivity, but not *when*
-  it happens ;p
- pinotree: right, it needs -rdynamic
-
-
-## IRC, freenode, #hurd, 2012-07-21
-
- tschwinge: my current "approach" is to introduce an infinite loop
- it makes the faulting task mapped in often enough to use gdb
-  through qemu
- ... :)
- My understanding is that glibc already does have some mechanism
-  for that: I have seen it print backtraces whendetecting malloc
-  inconsistencies (double free and the lite).
- yes, i thought it used the backtrace functions internally though
- that is, execinfo
- but this does require -rdynamic
-
-
-# GCC's libbacktrace
-
-Introduced in GCC commit ecd3459e7bb829202601e3274411135a15c64dde.
-- 
2.32.0

[PATCH 3/5] * open_issues/exec.mdwn: delete file.

[jbra...@dismail.de]

---
 open_issues/exec.mdwn | 84 ---
 1 file changed, 84 deletions(-)
 delete mode 100644 open_issues/exec.mdwn

diff --git a/open_issues/exec.mdwn b/open_issues/exec.mdwn
deleted file mode 100644
index 05deaa7a..
--- a/open_issues/exec.mdwn
+++ /dev/null
@@ -1,84 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2013 Free Software Foundation, Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled [[GNU Free Documentation
-License|/fdl]]."]]"""]]
-
-[[!tag open_issue_hurd]]
-
-[[!toc]]
-
-
-# IRC, unknown channel, unknown date.
-
- oh my, disabling gzip/bzip2 support makes apt preconfigure hang
- support in exec* I meant
-
- now a funny bug: if I disable gzip/bzip2 support from exec
- trying to run a zero-byte file hangs
-
-Justus: This doesn't seem to be an issue anymore (2013-09-08):
-
-% touch empty
-% chmod +x empty
-% ./empty
-zsh: exec format error: ./empty
-% bash
-$ ./empty
-$ 
-
-Also I've never encountered a problem with apt.
-
-
-## IRC, freenode, #hurd, 2013-08-01
-
- uh, all the non trivial exec server code has #ifdef'd BFD code
-  all over it and it looks like that isn't even used anymore
- that's too bad actually, I figured out how to get the values
-  from BFD, not so for the other elf parser that is used instead
-
-
-## IRC, freenode, #hurd, 2013-08-05
-
- btw, there is a Debian bug concerning zipped executables. now
-  I'm not sure if I understood the problem, but gziped and bzip2ed
-  executables work for me
- (not that I'm a big fan of that particular feature)
- iirc these somehow got fixed yes
- something like a previous out of bound access
- the exec server contains lot's of code that is unused and
-  probably bit rot (#ifdef BFD) or otherwise ignored (#if 0)
- yes :/
- and there's gunzipping and bunzip2ing, which we probably don't
-  want anyway
- why not?
- we should strip all that from exec and start adding features
- pinotree: b/c it's slow and the gain is questionable
- it breaks mmapping the code in
- exec/exec.c is huge (~2300 lines) and complex and it is an
-  essential server
- and I wonder if the unzipping is done securely, e. g. if it's
-  not possible to crash exec with an maliciously compressed executable
-
-
-## IRC, freenode, #hurd, 2013-09-12
-
- The zip code in hurd/exec/ looks really complicated; does it
-  really just unpack zipped files in memory (which could be replaced by
-  library calls) or is there something else going on?
- rekado:
-  http://lists.gnu.org/archive/html/bug-hurd/2013-08/msg00049.html
- braunr: interesting. Thanks.
- Does this mean that the "small hack entry" on the contributing
-  page to use libz and libbz2 in exec is no longer valid?
- probably
-

-
-May want to have a look at using BFD / libiberty/simpleobject.
-
-Justus: The BFD code has been removed from the exec server.
-- 
2.32.0

[PATCH 2/5] open_issues/exex_memory_leaks.mdwn: delete file.

[jbra...@dismail.de]

---
 open_issues/exec_memory_leaks.mdwn | 121 -
 1 file changed, 121 deletions(-)
 delete mode 100644 open_issues/exec_memory_leaks.mdwn

diff --git a/open_issues/exec_memory_leaks.mdwn 
b/open_issues/exec_memory_leaks.mdwn
deleted file mode 100644
index 1fc5a928..
--- a/open_issues/exec_memory_leaks.mdwn
+++ /dev/null
@@ -1,121 +0,0 @@
-[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled [[GNU Free Documentation
-License|/fdl]]."]]"""]]
-
-[[!tag open_issue_hurd]]
-
-There are is some memory leak in [[`exec`|hurd/translator/exec]].
-
-[[!toc]]
-
-
-# IRC, freenode, #hurd, 2012-08-11
-
- the exec servers seems to leak a lot
- server*
- exec now uses 109M on darnassus
- it really leaks a lot
- only 109mb? few months ago, exec on exodar was taking more than
-  200mb after few days of uptime with builds done
- i wonder how much it takes on the buildds
-
-
-## IRC, freenode, #hurd, 2012-08-17
-
- the exec leak is tricky
- bddebian: btw, look at the TODO file in the hurd source code
- bddebian: there is a not from thomas bushnell about that
- "*** Handle dead name notifications on execserver ports. !
- not sure it's still a todo item, but it might be worth checking
- braunr: diskfs_execboot_class = ports_create_class (0, 0);
-  This is what would need to change right?  It should call some cleanup
-  routine in the first argument?
- Would be ideal if it could just use deadboot() from exec.
- bddebian: possible
- bddebian: hum execboot, i'm not so sure
- Execboot is the exec task, no?
- i don't know what execboot is
- It's from libdiskfs
- but "diskfs_execboot_class" looks like a class of ports used at
-  startup only
- ah
- then it's something run in the diskfs users ?
- yes
- the leak is in exec
- if clients misbehave, it shouldn't affect that server
- That's a different issue, this was about the TODO thing 
- ah
- i don't know
- Me either :)
- For the leak I'm still focusing on do-bunzip2 but I am baffled
-  at my results..
- ?
- Where my counters are zero if I always increment on different
-  vars but wild freaking numbers if I increment on malloc and decrement on
-  free
-
-
-# 2012-11-25
-
-After twelve hours worth of `fork/exec` ([[GCC]]'s `check-c` part of the
-testsuite), we got:
-
-  PID  UID  PPID  PGrp  Sess TH  Vmem   RSS %CPU User   System Args
-40 3 1 1 10  392M  262M  0.0  2:18.29 2hrs 
/hurd/exec
-
-The *RSS* seems a tad high.  Also the system part of CPU time consumption is
-quite noticeable.  In comparison:
-
-00 1 1 1 19  131M 1.14M  0.0  3:30.25  9:17.79 
/hurd/proc
-30 1 1 1 224 405M 12.6M  0.2 42:20.2567min ext2fs 
--readonly --multiboot-command-line=root=device:hd0s6 --host-priv-port=1 
--device-master-port=2 --exec-server-task=3 -T typed device:hd0s6
-  2760 3 1 1 344 442M 28.2M  0.6 48:09.3691min 
/hurd/ext2fs /dev/hd2s5
-
-
-# 2012-12-20
-
-After running the libtool testsuite for some time:
-
-  PID TH#  UID  PPID  PGrp  Sess TH  Vmem   RSS %CPU User   System Args
-40 3 1 1 11  334M  203M 60.8  3:19.73 4hrs 
/hurd/exec
-00.0  0:20.33 27:02.47 
-10.0  0:31.10 32:21.13 
-20.0  0:25.68 27:42.33 
-30.0  0:00.00  0:00.00 
-45.1  0:34.93 34:07.59 
-50.0  0:19.56 28:44.15 
-63.4  0:18.73 28:17.89 
-70.0  0:20.47 34:42.51 
-8   39.5  0:15.60 28:48.57 
-90.0  0:04.49 10:24.12 
-   10   12.8  0:08.84 19:34.45 
-
-
-# IRC, freenode, #hurd, 2013-10-08
-
-* braunr hunting the exec leak
- and i think i found it
- yes :>
- testing a bit more and committing the fix later tonight
- pinotree: i've been building glibc for 40 mins and exec is still
-  consuming around 1m memory
- wow nice
- i've been noticing exec leaking quite some time 

[PATCH 1/5] open_issues/Upstart.mdwn: delete file.

[jbra...@dismail.de]

---
We have no interest in supporting Upstart since it it a dead project.

 open_issues/Upstart.mdwn | 69 
 1 file changed, 69 deletions(-)
 delete mode 100644 open_issues/Upstart.mdwn

diff --git a/open_issues/Upstart.mdwn b/open_issues/Upstart.mdwn
deleted file mode 100644
index 1972e197..
--- a/open_issues/Upstart.mdwn
+++ /dev/null
@@ -1,69 +0,0 @@
-[[!meta copyright="Copyright © 2013, 2014 Free Software Foundation, Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled [[GNU Free Documentation
-License|/fdl]]."]]"""]]
-
-
-[[!template id=highlight text="""/!\ Obsolete /!\
-

-
-[[systemd|Systemd]] has almost universally replaced upstart."""]]
-
-Upstart is an event based init system that is GPL licensed, however upstream
-contributions are under a CLA that permits proprietary relicensing.
-
-Most major GNU/Linux distributions are choosing systemd as their init system
-instead of upstart.  The original upstart developers seem to have stopped
-developing it.
-
-The following are the words of Colin Watson on the debian-c...@lists.debian.org
-mailing list and list the requirements of a potential HURD port:
-
->I haven't looked at this in much detail, and I suspect Dimitri hasn't
-yet although IIRC he did express some interest in doing so.  But I
-haven't seen anyone else try to outline the scope of a port, so let me
-try to do so for the sake of general understanding.  As far as I know,
-the hardest parts would be inotify, ptrace, and prctl
-(PR_SET_CHILD_SUBREAPER).
-
->inotify is used to notice changes to configuration files.  This is
-certainly helpful for users, but it isn't critical as "initctl
-reload-configuration" works without it.  We could probably do without
-this with the aid of a dpkg trigger.
-
->ptrace is used for "expect fork" and "expect daemon"; as I indicated in
-another post, I think it would be preferable to avoid these in Debian
-and quite possibly to compile them out.  (This would mean we wouldn't be
-able to translate Ubuntu jobs quite as directly, and a number of
-important jobs would definitely need to be changed, but the conversion
-isn't usually particularly difficult.)
-
->prctl (PR_SET_CHILD_SUBREAPER) is used to make SIGCHLD notification work
-properly when Upstart is supervising a user session.  This isn't a
-required feature and could easily be compiled out until suitable kernel
-support is available (this actually seems like the sort of thing that
-could be done in the Hurd without too much difficulty, but I haven't
-looked into it).  If absent, it might well impede the ability to do an
-advanced desktop port, but it wouldn't get in the way of porting the
-bulk of services.
-
->There might also be odds and ends around the details of wait status
-handling.
-
-inotify seems to be a feature that is often used in GNU/Linux programs, and
-implementing the feature in the HURD seems like a better and more rewarding
-option than porting the code in Upstart.
-
-Although many daemons double fork, that behavior seems to be dying out, and
-one can comfortably ignore the "expect fork/daemon" functionality of Upstart
-(and compile it out).
-
-[[!tag open_issue_porting]]
-
-See also the discussion about upstart on the [[systemd]] page.
-- 
2.32.0

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

[Guy-Fleury Iteriteka]

On May 15, 2023 4:38:34 PM GMT+02:00, "jbra...@dismail.de"  
wrote:
>---
>I explained that the Hurd has initial 64-bit support, but I 
>did not mention if the project plans to drop 32-bit
>support.  Joshua
>
> faq/64-bit.mdwn  | 10 +++---
> open_issues/64-bit_port.mdwn |  6 +-
> 2 files changed, 4 insertions(+), 12 deletions(-)
>
>diff --git a/faq/64-bit.mdwn b/faq/64-bit.mdwn
>index 2e1278cb..82513d25 100644
>--- a/faq/64-bit.mdwn
>+++ b/faq/64-bit.mdwn
>@@ -13,11 +13,7 @@ License|/fdl]]."]]"""]]
> 
> [[!meta title="Is there a 64-bit version?"]]
> 
>-There are currently no plan for 64-bit userland for the short term, but there
>-are plans for 64-bit kernelland with 32-bit userland, which will notably 
>permit
>-to efficiently make use of more than 2 GiB memory and provide 4 GiB userland
>-addressing space. The kernel support was merged into GNU Mach, the currently
>-missing bit is the 32/64 mig translation for kernel RPCs.
>+As of May 2023, the Hurd developers have a bootable 64-bit Debian
Are sure a debian hurd boot??
>+GNU/Hurd.  The 64 bit kernel and userspace is mostly working, but bugs
>+still need to be fixed.
> 
>-That being said, you can always run a 32-bit version on a 64-bit machine, it
>-just works, processes are just limited to a couple GiB available memory.
>diff --git a/open_issues/64-bit_port.mdwn b/open_issues/64-bit_port.mdwn
>index 95761828..ca30ba64 100644
>--- a/open_issues/64-bit_port.mdwn
>+++ b/open_issues/64-bit_port.mdwn
>@@ -13,11 +13,7 @@ License|/fdl]]."]]"""]]
> 
> [[!inline pages="title(Is there a 64-bit version?)" feeds="no" raw="yes"]]
> 
>-**What is left for initial support (32-on-64) is**
>-
>-  * Fixing bugs :)
>-
>-**For pure 64bit support, we need to**
>+**For 64-bit support, we need to**
> 
>   * Fix bugs :)
>   * bootstrap a distrib

Hi,

[PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

[jbra...@dismail.de]

---
I explained that the Hurd has initial 64-bit support, but I 
did not mention if the project plans to drop 32-bit
support.  Joshua

 faq/64-bit.mdwn  | 10 +++---
 open_issues/64-bit_port.mdwn |  6 +-
 2 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/faq/64-bit.mdwn b/faq/64-bit.mdwn
index 2e1278cb..82513d25 100644
--- a/faq/64-bit.mdwn
+++ b/faq/64-bit.mdwn
@@ -13,11 +13,7 @@ License|/fdl]]."]]"""]]
 
 [[!meta title="Is there a 64-bit version?"]]
 
-There are currently no plan for 64-bit userland for the short term, but there
-are plans for 64-bit kernelland with 32-bit userland, which will notably permit
-to efficiently make use of more than 2 GiB memory and provide 4 GiB userland
-addressing space. The kernel support was merged into GNU Mach, the currently
-missing bit is the 32/64 mig translation for kernel RPCs.
+As of May 2023, the Hurd developers have a bootable 64-bit Debian
+GNU/Hurd.  The 64 bit kernel and userspace is mostly working, but bugs
+still need to be fixed.
 
-That being said, you can always run a 32-bit version on a 64-bit machine, it
-just works, processes are just limited to a couple GiB available memory.
diff --git a/open_issues/64-bit_port.mdwn b/open_issues/64-bit_port.mdwn
index 95761828..ca30ba64 100644
--- a/open_issues/64-bit_port.mdwn
+++ b/open_issues/64-bit_port.mdwn
@@ -13,11 +13,7 @@ License|/fdl]]."]]"""]]
 
 [[!inline pages="title(Is there a 64-bit version?)" feeds="no" raw="yes"]]
 
-**What is left for initial support (32-on-64) is**
-
-  * Fixing bugs :)
-
-**For pure 64bit support, we need to**
+**For 64-bit support, we need to**
 
   * Fix bugs :)
   * bootstrap a distrib
-- 
2.32.0

[PATCH 2/4] hurd: Align signal stack pointer after allocating stackframe

[Sergey Bugaev]

sizeof (*stackframe) appears to be divisible by 16, but we should not
rely on that. So make sure to leave enough space for the stackframe
first, and then align the final pointer at 16 bytes.

Checked on x86_64-gnu.

Signed-off-by: Sergey Bugaev 
---
 sysdeps/mach/hurd/x86/trampoline.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/sysdeps/mach/hurd/x86/trampoline.c 
b/sysdeps/mach/hurd/x86/trampoline.c
index 19bddad8..1f92064e 100644
--- a/sysdeps/mach/hurd/x86/trampoline.c
+++ b/sysdeps/mach/hurd/x86/trampoline.c
@@ -196,15 +196,14 @@ _hurd_setup_sighandler (struct hurd_sigstate *ss, const 
struct sigaction *action
 #endif
 }
 
+  /* Push the arguments to call `trampoline' on the stack.  */
+  sigsp -= sizeof (*stackframe);
 #ifdef __x86_64__
   /* Align SP at 16 bytes.  Coupled with the fact that sigreturn_addr is
  16-byte aligned within the stackframe struct, this ensures that it ends
  up on a 16-byte aligned address, as required by the ABI.  */
   sigsp = (void *) ((uintptr_t) sigsp & ~15UL);
 #endif
-
-  /* Push the arguments to call `trampoline' on the stack.  */
-  sigsp -= sizeof (*stackframe);
   stackframe = sigsp;
 
   if (_hurdsig_catch_memory_fault (stackframe))
-- 
2.40.1

[PATCH 0/4] x86_64-gnu signal fixes

[Sergey Bugaev]

Hello,

now that we got enough of the system running on x86_64-gnu, we can
actually test the signal machinery. In fact we sort of *have to*,
because /bin/sh receives SIGCHLD when a command completes, and wants
to handle it.

Suprisingly, most of the logic actually does just work! -- but several
things were broken; and this patch series contains the fixes. With
these patches (+ the thread setup fixes that I'll send as a separate
series) I'm able to receive a signal, do all the trampoline and
intr-rpc magic, run the handler, and sigreturn back into user code --
apparently successfully.

Sergey

[PATCH 4/4] hurd: Fix computing user stack pointer

[Sergey Bugaev]

Fixes b574ae0a2876ee94e4fe617f878407bf818c2df0
"hurd: Implement sigreturn for x86_64"

Checked on x86_64-gnu.

Signed-off-by: Sergey Bugaev 
---
 sysdeps/mach/hurd/x86_64/sigreturn.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sysdeps/mach/hurd/x86_64/sigreturn.c 
b/sysdeps/mach/hurd/x86_64/sigreturn.c
index 82247e3c..5d3a4d31 100644
--- a/sysdeps/mach/hurd/x86_64/sigreturn.c
+++ b/sysdeps/mach/hurd/x86_64/sigreturn.c
@@ -126,7 +126,7 @@ __sigreturn (struct sigcontext *scp)
copy the registers onto the user's stack, switch there, pop and
return.  */
 
-uintptr_t *usp = (uintptr_t *) scp->sc_ursp - 128;
+uintptr_t *usp = (uintptr_t *) (scp->sc_ursp - 128);
 
 *--usp = scp->sc_rip;
 *--usp = scp->sc_rfl;
-- 
2.40.1

[PATCH 3/4] hurd: Fix sc_i386_thread_state layout

[Sergey Bugaev]

The real i386_thread_state Mach structure has an alignment of 8 on
x86_64. However, in struct sigcontext, the compiler was packing sc_gs
(which is the first member of sc_i386_thread_state) into the same 8-byte
slot as sc_error; this resulted in the rest of sc_i386_thread_state
members having wrong offsets relative to each other, and the overall
sc_i386_thread_state layout mismatching that of i386_thread_state.

Fix this by explicitly adding the required padding members, and
statically asserting that this results in the desired alignment.

The same goes for sc_i386_float_state.

Checked on x86_64-gnu.

Signed-off-by: Sergey Bugaev 
---
 sysdeps/mach/hurd/x86/trampoline.c | 6 ++
 sysdeps/mach/hurd/x86_64/bits/sigcontext.h | 8 
 2 files changed, 14 insertions(+)

diff --git a/sysdeps/mach/hurd/x86/trampoline.c 
b/sysdeps/mach/hurd/x86/trampoline.c
index 1f92064e..6318c952 100644
--- a/sysdeps/mach/hurd/x86/trampoline.c
+++ b/sysdeps/mach/hurd/x86/trampoline.c
@@ -242,11 +242,17 @@ _hurd_setup_sighandler (struct hurd_sigstate *ss, const 
struct sigaction *action
 
   /* struct sigcontext is laid out so that starting at sc_gs mimics a
 struct i386_thread_state.  */
+  _Static_assert (offsetof (struct sigcontext, sc_i386_thread_state)
+ % __alignof__ (struct i386_thread_state) == 0,
+ "sc_i386_thread_state layout mismatch");
   memcpy (>sc_i386_thread_state,
  >basic, sizeof (state->basic));
 
   /* struct sigcontext is laid out so that starting at sc_fpkind mimics
 a struct i386_float_state.  */
+  _Static_assert (offsetof (struct sigcontext, sc_i386_float_state)
+ % __alignof__ (struct i386_float_state) == 0,
+ "sc_i386_float_state layout mismatch");
   ok = machine_get_state (ss->thread, state, i386_FLOAT_STATE,
  >fpu, >sc_i386_float_state,
  sizeof (state->fpu));
diff --git a/sysdeps/mach/hurd/x86_64/bits/sigcontext.h 
b/sysdeps/mach/hurd/x86_64/bits/sigcontext.h
index 3a3b34bc..63960544 100644
--- a/sysdeps/mach/hurd/x86_64/bits/sigcontext.h
+++ b/sysdeps/mach/hurd/x86_64/bits/sigcontext.h
@@ -46,6 +46,11 @@ struct sigcontext
 /* Error code associated with this signal (interpreted as `error_t').  */
 int sc_error;
 
+/* Make sure the below members are properly aligned, and not packed
+   together with sc_error -- otherwise the layout won't match that of
+   i386_thread_state.  */
+int sc_pad1;
+
 /* All following members are machine-dependent.  The rest of this
structure is written to be laid out identically to:
{
@@ -86,6 +91,9 @@ struct sigcontext
 long sc_ursp;  /* This stack pointer is used.  */
 int sc_ss; /* Stack segment register.  */
 
+/* Make sure the below has the same layout as i386_float_state.  */
+int sc_pad2;
+
 /* Following mimics struct i386_float_state.  Structures and symbolic
values can be found in .  */
 #define sc_i386_float_state sc_fpkind
-- 
2.40.1

[PATCH 1/4] hurd: Fix aligning signal stack pointer

[Sergey Bugaev]

Fixes 60f9bf974694d50daf58d46347b06a5975ac5ddd
"hurd: Port trampoline.c to x86_64"

Checked on x86_64-gnu.

Reported-by: Bruno Haible 
Signed-off-by: Sergey Bugaev 
---
 sysdeps/mach/hurd/x86/trampoline.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sysdeps/mach/hurd/x86/trampoline.c 
b/sysdeps/mach/hurd/x86/trampoline.c
index e13c5d85..19bddad8 100644
--- a/sysdeps/mach/hurd/x86/trampoline.c
+++ b/sysdeps/mach/hurd/x86/trampoline.c
@@ -200,7 +200,7 @@ _hurd_setup_sighandler (struct hurd_sigstate *ss, const 
struct sigaction *action
   /* Align SP at 16 bytes.  Coupled with the fact that sigreturn_addr is
  16-byte aligned within the stackframe struct, this ensures that it ends
  up on a 16-byte aligned address, as required by the ABI.  */
-  sigsp = (void *) ((uintptr_t) sigsp & 16UL);
+  sigsp = (void *) ((uintptr_t) sigsp & ~15UL);
 #endif
 
   /* Push the arguments to call `trampoline' on the stack.  */
-- 
2.40.1

[PATCH] x86_64: Fix reporting fsgs base in thread_get_state ()

[Sergey Bugaev]

Fixes 31dd30a94a682955c3c9e2f42252b4a07687067a "add setting gs/fsbase".
---
This was breaking fork () in glibc when it tried to set up TLS in the
new process by copying fs_base from an existing thread.

 i386/i386/pcb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/i386/i386/pcb.c b/i386/i386/pcb.c
index a5efb9a8..fb535709 100644
--- a/i386/i386/pcb.c
+++ b/i386/i386/pcb.c
@@ -873,7 +873,7 @@ kern_return_t thread_getstatus(
 
 state = (struct i386_fsgs_base_state *) tstate;
 state->fs_base = thread->pcb->iss.fsbase;
-state->fs_base = thread->pcb->iss.gsbase;
+state->gs_base = thread->pcb->iss.gsbase;
 *count = i386_FSGS_BASE_STATE_COUNT;
 break;
 }
-- 
2.40.1

[PATCH v2 4/4] Cosmetic tweaks

[Sergey Bugaev]

---
 proc/msg.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/proc/msg.c b/proc/msg.c
index 25ce0d5b..93ad995b 100644
--- a/proc/msg.c
+++ b/proc/msg.c
@@ -80,7 +80,7 @@ S_proc_setmsgport (struct proc *p,
  perror ("pthread_create");
}
 }
-  
+
   return 0;
 }
 
@@ -107,7 +107,7 @@ check_msgport_death (struct proc *p)
 {
   mach_port_type_t type;
   error_t err;
-  
+
   err = mach_port_type (mach_task_self (), p->p_msgport, );
   if (err || (type & MACH_PORT_TYPE_DEAD_NAME))
{
-- 
2.40.1

[PATCH v2 2/4] proc: Report CPU_TYPE_X86_64 in uname as "x86_64"

[Sergey Bugaev]

This fixes a proc server crash during startup inside
initialize_version_info ().
---
 proc/cpu-types.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/proc/cpu-types.c b/proc/cpu-types.c
index 3d89d5a7..89787d3d 100644
--- a/proc/cpu-types.c
+++ b/proc/cpu-types.c
@@ -30,6 +30,9 @@ const char *const mach_cpu_types[] =
 #ifdef CPU_TYPE_PENTIUMPRO
 [CPU_TYPE_PENTIUMPRO] = "i686",
 #endif
+#ifdef CPU_TYPE_X86_64
+[CPU_TYPE_X86_64] = "x86_64",
+#endif
 #ifdef CPU_TYPE_POWERPC
 [CPU_TYPE_POWERPC] = "powerpc",
 #endif
-- 
2.40.1

[PATCH v2 3/4] proc: Don't buffer Mach console output

[Sergey Bugaev]

Normally glibc does not buffer tty output, but a devstream backed by
the Mach console device cannot be isatty'ed. So we need to ask glibc
explicitly to not buffer it. This is what the startup and mach-defpager
do already.
---
 proc/main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/proc/main.c b/proc/main.c
index 8a2dc9ff..747646ef 100644
--- a/proc/main.c
+++ b/proc/main.c
@@ -132,6 +132,7 @@ open_console (mach_port_t device_master)
 
   stdin = mach_open_devstream (cons, "r");
   stdout = stderr = mach_open_devstream (cons, "w");
+  setbuf (stdout, NULL);
 
   got_console = 1;
   mach_port_deallocate (mach_task_self (), cons);
-- 
2.40.1

[PATCH v2 1/4] exec: Allow loading x86_64 executables on x86_64

[Sergey Bugaev]

Since we don't support mixing i386 and x86_64 binaries on the same
system (as running them requires different build-time gnumach
configurations), the exec server can simply require the binary being
loaded to have been built for the same architecture as the exec server
itself.
---
 exec/exec.c | 8 +++-
 exec/hostarch.c | 9 +
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/exec/exec.c b/exec/exec.c
index 8944167d..2e5fbfcd 100644
--- a/exec/exec.c
+++ b/exec/exec.c
@@ -518,6 +518,12 @@ prepare (file_t file, struct execdata *e)
 #define host_ELFDATA ELFDATA2LSB
 #endif
 
+#ifdef __LP64__
+#define host_ELFCLASS ELFCLASS64
+#else
+#define host_ELFCLASS ELFCLASS32
+#endif
+
 static void
 check_elf (struct execdata *e)
 {
@@ -539,7 +545,7 @@ check_elf (struct execdata *e)
   return;
 }
 
-  if (ehdr->e_ident[EI_CLASS] != ELFCLASS32 ||
+  if (ehdr->e_ident[EI_CLASS] != host_ELFCLASS ||
   ehdr->e_ident[EI_DATA] != host_ELFDATA ||
   ehdr->e_ident[EI_VERSION] != EV_CURRENT ||
   ehdr->e_version != EV_CURRENT ||
diff --git a/exec/hostarch.c b/exec/hostarch.c
index 363fda69..ed50e0a8 100644
--- a/exec/hostarch.c
+++ b/exec/hostarch.c
@@ -72,6 +72,15 @@ elf_machine_matches_host (ElfW(Half) e_machine)
 case CPU_TYPE_PENTIUMPRO:
   CACHE (e_machine == EM_386);
 
+/* When building for x86_64, CPU_TYPE_X86_64 must be defined; otherwise
+   it's OK if we don't compile this branch -- none of the branches other
+   than the actual architecture the code is built for are going to be
+   taken anyway.  */
+#if defined (CPU_TYPE_X86_64) || defined (__x86_64__)
+case CPU_TYPE_X86_64:
+  CACHE (e_machine == EM_X86_64);
+#endif
+
 case CPU_TYPE_POWERPC:
   CACHE (e_machine == EM_PPC);
 
-- 
2.40.1

Re: [PATCH glibc] Stop checking if MiG supports retcode.

[Sergey Bugaev]

On Mon, May 15, 2023 at 9:19 AM Sergey Bugaev  wrote:
> On Mon, May 15, 2023 at 7:09 AM Flávio Cruz  wrote:
> > If we want
> > ./configure to check if MiG generates code to call the server reply routine
> > in case of errors (it doesn't :() then we will need to build a different 
> > check.
>
> Huh? Why would MIG call that? Maybe I'm missing some context.

Ah, I think I see what you might have meant.

Are you thinking that the _reply subsystem defines the proper,
canonical format for reply messages to the  subsystem? -- and that
MIG should call those instead of doing its own logic for generating a
reply message?

If that's what you mean, then, well, no. The reply format for each RPC
is fully defined by its declaration in the .defs. Specifically: it
has msgh_id +100 compared to the request RPC, the first value in the
message body is the RetCode, and then all the out or inout arguments,
in order.

Moreover, there doesn't have to be a _reply subsystem
generated/compiled/linked into the server program. Those servers that
want it, they do use it, others don't.

_reply subsystem is fully independent from the original 
subsystem as far as MIG is concerned. It's a *trick* (described in my
previous message) used by programs to make and handle requests
asynchronously *without* altering the wire/message format. The
_reply subsystem is supposed to *mimic* the format of 
subsystem's reply messages, not *define* it. It should be completely
*transparent* to a client program that calls e.g. io_select, whether
the server implements it synchronously (as e.g. pflocal does) or
asynchronously (with MIG_NO_REPLY + an eventual io_select_reply, as my
epoll server implementation does). The retcode specifier in
_reply.defs is designed to fix the (hopefully only) difference in
wire format between actual replies of the  subsystem and the
simpleroutines of the _reply subsystem.

I hope that makes sense. And if that's not what you've meant, please
explain what it was :)

Sergey

Re: [PATCH glibc] Stop checking if MiG supports retcode.

[Sergey Bugaev]

Hi,

On Mon, May 15, 2023 at 7:09 AM Flávio Cruz  wrote:
> If we want
> ./configure to check if MiG generates code to call the server reply routine
> in case of errors (it doesn't :() then we will need to build a different 
> check.

Huh? Why would MIG call that? Maybe I'm missing some context. Here's
my understanding of what the retcode specifier is for:

The use cases for the _reply subsystems are:

* On the client/user side, only sending the request as a simpleroutine,
  and then handling the eventual reply, asynchronously, as a request in
  its own right (S_x_reply).
* On the server side, returning MIG_NO_REPLY from a routine
  implementation, and then replying asynchronously using the _reply
  simpleroutine.

The special handling for retcode arguments is needed to:

* On the server side, when calling _reply (this is the *user* side
  as far as MIG is concerned), if the RetCode is non-0, MIG should not
  serialize all the other arguments into the message, just like it
  normally does when a server-side routine implementation returns
  non-0.
* On the client side, when handling an incoming _reply request
  (this is the *server* side as far as MIG is concerned), MIG should
  not reject the request on the basis of a failed type/size check if
  its RetCode is non-0, because this is how error replies are supposed
  to be. It should still call the routine implementation
  (S__reply), passing either zeroes out, or I guess just garbage
  values would work as well, for the missing arguments.

This MIG_NO_REPLY + asynchronous explicit reply pattern is rarely used
on the Hurd; most of the servers are written to just block the routine
implementation on a conditional variable or something like that, and
reply synchronously. Which is probably why we've been able to get away
with not supporting retcode properly.

Sergey