Re: [PATCH glibc] Define PC, SP and SYSRETURN for hurd x86_64

[Sergey Bugaev]

On Wed, Feb 15, 2023 at 9:17 AM Flavio Cruz  wrote:
>
> Moved thread_state.h to x86 directory since we only need to customize
> those 3 definitions.

No, that won't be enough. We also need to customize those
MACHINE_THREAD_STATE_FLAVOR definitions to include the potential new
i386_FSGS_BASE_STATE that we were discussing recently [0].

[0] https://sourceware.org/pipermail/libc-alpha/2023-February/145528.html

I was just looking at this file yesterday and concluded the
MACHINE_THREAD_STATE_FLAVOR / MACHINE_NEW_THREAD_STATE_FLAVOR
abstraction cannot work as is for x86_64, because half of the time
it's used for indeed accessing registers like SP and PC, and other
times it's used to access TLS/TCB. So this needs to be two distinct
definitions, and all the users inside glibc have to be reworked.

So let's please not rush with moving this to x86/

Sergey

[PATCH gnumach] Define prototype for bogus in gensym.awk

[Flavio Cruz]

Otherwise gcc will complain that bogus does not have a prototype.
---
 gensym.awk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gensym.awk b/gensym.awk
index 63c2f440..609d9273 100644
--- a/gensym.awk
+++ b/gensym.awk
@@ -27,6 +27,7 @@ BEGIN {
 /^[a-z]/ {
if (bogus_printed == "no")
{
+   print "void bogus(void);"
print "void bogus(void) {";
bogus_printed = "yes";
}
-- 
2.39.0

[PATCH glibc] Define PC, SP and SYSRETURN for hurd x86_64

[Flavio Cruz]

Moved thread_state.h to x86 directory since we only need to customize
those 3 definitions.
---
 sysdeps/mach/{i386 => x86}/thread_state.h | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)
 rename sysdeps/mach/{i386 => x86}/thread_state.h (90%)

diff --git a/sysdeps/mach/i386/thread_state.h b/sysdeps/mach/x86/thread_state.h
similarity index 90%
rename from sysdeps/mach/i386/thread_state.h
rename to sysdeps/mach/x86/thread_state.h
index 4e6ce1f7dd..5be0bec150 100644
--- a/sysdeps/mach/i386/thread_state.h
+++ b/sysdeps/mach/x86/thread_state.h
@@ -16,8 +16,8 @@
License along with the GNU C Library; if not, see
.  */
 
-#ifndef _MACH_I386_THREAD_STATE_H
-#define _MACH_I386_THREAD_STATE_H 1
+#ifndef _MACH_X86_THREAD_STATE_H
+#define _MACH_X86_THREAD_STATE_H 1
 
 #include 
 
@@ -29,9 +29,15 @@
 
 #define machine_thread_state i386_thread_state
 
+#ifdef __x86_64__
+#define PC rip
+#define SP ursp
+#define SYSRETURN rax
+#else
 #define PC eip
 #define SP uesp
 #define SYSRETURN eax
+#endif
 
 #define MACHINE_THREAD_STATE_FIX_NEW(ts) do { \
asm ("mov %%cs, %w0" : "=q" ((ts)->cs)); \
@@ -50,4 +56,4 @@ struct machine_thread_all_state
 
 #include 
 
-#endif /* mach/i386/thread_state.h */
+#endif /* mach/x86/thread_state.h */
-- 
2.39.1

Re: checking whether mig supports the retcode keyword... no

[Flávio Cruz]

Hey Sergey

On Tue, Feb 14, 2023 at 8:49 AM Sergey Bugaev  wrote:

> This line in configure logs has always bugged me; of course GNU MIG
> supports "retcode" (as in, does not report an error upon seeing it).
> Today I happened to have journalctl -f opened at the time I ran
> ../configure, and accidentally found out why this happens:
>
> kernel: traps: x86_64-gnu-migc[177175] trap divide error ip:40befb
> sp:7ffc84726920 error:0 in x86_64-gnu-migcom[401000+1]
>
> oh noes!
>
> $ coredumpctl debug
> 
> Core was generated by
> `/home/sergey/dev/crosshurd64/bin/../libexec/x86_64-gnu-migcom -n'.
> Program terminated with signal SIGFPE, Arithmetic exception.
> #0  0x0040befb in itVarArrayDecl (number=0, old=0xb285e0) at
> ../type.c:632
> 632 it->itNumber = (2048 / bytes) * it->itNumber;
> (gdb) bt
> #0  0x0040befb in itVarArrayDecl (number=0, old=0xb285e0) at
> ../type.c:632
> #1  0x004059ef in yyparse () at ../parser.y:474
> #2  0x004012c9 in main (argc=, argv= out>) at ../migcom.c:218
> (gdb) p bytes
> $1 = 0
> (gdb) p *old
> $2 = {itName = 0x0, itNext = 0x0, itTypeSize = 0, itPadSize = 0,
> itMinTypeSize = 0, itAlignment = 0, itInName = 0, itOutName = 0,
> itSize = 0, itNumber = 1, itInLine = true, itLongForm = false,
>   itDeallocate = d_NO, itInNameStr = 0x0, itOutNameStr = 0x0, itFlags
> = 0, itStruct = true, itString = false, itVarArray = false,
> itIndefinite = false, itKernelPort = false, itElement = 0x0,
>   itUserType = 0x0, itServerType = 0x0, itTransType = 0x0, itInTrans =
> 0x0, itInTransPayload = 0x0, itOutTrans = 0x0, itDestructor = 0x0}
>
> That type doesn't look right! But then I looked at the configure log
> and found this:
>
> configure:4633: checking whether x86_64-gnu-mig supports the retcode
> keyword
> configure:4650: CC=x86_64-gnu-gcc x86_64-gnu-mig -n conftest.defs 1>&5
> "/home/sergey/dev/crosshurd64/include/mach/std_types.defs", line 32:
> Basic types not initialized when looking up type int32_t. Did you
> forget to define the subsystem?
> "/home/sergey/dev/crosshurd64/include/mach/std_types.defs", line 33:
> Basic types not initialized when looking up type int64_t. Did you
> forget to define the subsystem?
> "/home/sergey/dev/crosshurd64/include/mach/std_types.defs", line 34:
> Basic types not initialized when looking up type boolean_t. Did you
> forget to define the subsystem?
> "/home/sergey/dev/crosshurd64/include/mach/std_types.defs", line 35:
> Basic types not initialized when looking up type unsigned. Did you
> forget to define the subsystem?
> "/home/sergey/dev/crosshurd64/include/mach/std_types.defs", line 36:
> Basic types not initialized when looking up type uint32_t. Did you
> forget to define the subsystem?
> "/home/sergey/dev/crosshurd64/include/mach/std_types.defs", line 37:
> Basic types not initialized when looking up type uint64_t. Did you
> forget to define the subsystem?
> "/home/sergey/dev/crosshurd64/include/mach/x86_64/machine_types.defs",
> line 45: Basic types not initialized when looking up type uint32_t.
> Did you forget to define the subsystem?
> "/home/sergey/dev/crosshurd64/include/mach/x86_64/machine_types.defs",
> line 45: type 'uint32_t' not defined
> "/home/sergey/dev/crosshurd64/include/mach/x86_64/machine_types.defs",
> line 45: Basic types not initialized when looking up type natural_t.
> Did you forget to define the subsystem?
> "/home/sergey/dev/crosshurd64/include/mach/x86_64/machine_types.defs",
> line 54: Basic types not initialized when looking up type int32_t. Did
> you forget to define the subsystem?
> "/home/sergey/dev/crosshurd64/include/mach/x86_64/machine_types.defs",
> line 54: type 'int32_t' not defined
> "/home/sergey/dev/crosshurd64/include/mach/x86_64/machine_types.defs",
> line 54: Basic types not initialized when looking up type integer_t.
> Did you forget to define the subsystem?
> "/home/sergey/dev/crosshurd64/include/mach/x86_64/machine_types.defs",
> line 65: Basic types not initialized when looking up type uint64_t.
> Did you forget to define the subsystem?
> "/home/sergey/dev/crosshurd64/include/mach/x86_64/machine_types.defs",
> line 65: type 'uint64_t' not defined
> "/home/sergey/dev/crosshurd64/include/mach/x86_64/machine_types.defs",
> line 65: Basic types not initialized when looking up type
> rpc_long_natural_t. Did you forget to define the subsystem?
> "/home/sergey/dev/crosshurd64/include/mach/x86_64/machine_types.defs",
> line 66: Basic types not initialized when looking up type int64_t. Did
> you forget to define the subsystem?
> "/home/sergey/dev/crosshurd64/include/mach/x86_64/machine_types.defs",
> line 66: type 'int64_t' not defined
> "/home/sergey/dev/crosshurd64/include/mach/x86_64/machine_types.defs",
> line 66: Basic types not initialized when looking up type
> rpc_long_integer_t. Did you forget to define the subsystem?
> "/home/sergey/dev/crosshurd64/include/mach/x86_64/machine_types.defs",
> line 78: Basic types not initialized when looking up type
> 

[PATCH gnumach] Rename efl to rfl for x86_64 in struct i386_thread_state

[Flavio Cruz]

---
 i386/i386/pcb.c| 13 -
 i386/include/mach/i386/thread_status.h |  2 +-
 2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/i386/i386/pcb.c b/i386/i386/pcb.c
index de30197e..9210656b 100644
--- a/i386/i386/pcb.c
+++ b/i386/i386/pcb.c
@@ -518,6 +518,8 @@ kern_return_t thread_setstatus(
saved_state->ecx = state->rcx;
saved_state->eax = state->rax;
saved_state->eip = state->rip;
+   saved_state->efl = (state->rfl & ~EFL_USER_CLEAR)
+   | EFL_USER_SET;
 #else
saved_state->edi = state->edi;
saved_state->esi = state->esi;
@@ -528,14 +530,14 @@ kern_return_t thread_setstatus(
saved_state->ecx = state->ecx;
saved_state->eax = state->eax;
saved_state->eip = state->eip;
-#endif /* __x86_64__ && !USER32 */
saved_state->efl = (state->efl & ~EFL_USER_CLEAR)
| EFL_USER_SET;
+#endif /* __x86_64__ && !USER32 */
 
/*
 * Segment registers.  Set differently in V8086 mode.
 */
-   if (state->efl & EFL_VM) {
+   if (saved_state->efl & EFL_VM) {
/*
 * Set V8086 mode segment registers.
 */
@@ -559,7 +561,7 @@ kern_return_t thread_setstatus(
 * Hardware assist on.
 */
thread->pcb->ims.v86s.flags =
-   state->efl & (EFL_TF | EFL_IF);
+   saved_state->efl & (EFL_TF | EFL_IF);
}
}
else if (flavor == i386_THREAD_STATE) {
@@ -734,6 +736,7 @@ kern_return_t thread_getstatus(
state->rax = saved_state->eax;
state->rip = saved_state->eip;
state->ursp = saved_state->uesp;
+   state->rfl = saved_state->efl;
state->rsp = 0; /* unused */
 #else
state->edi = saved_state->edi;
@@ -745,9 +748,9 @@ kern_return_t thread_getstatus(
state->eax = saved_state->eax;
state->eip = saved_state->eip;
state->uesp = saved_state->uesp;
+   state->efl = saved_state->efl;
state->esp = 0; /* unused */
 #endif /* __x86_64__ && !USER32 */
-   state->efl = saved_state->efl;
 
state->cs = saved_state->cs;
state->ss = saved_state->ss;
@@ -767,7 +770,7 @@ kern_return_t thread_getstatus(
if ((thread->pcb->ims.v86s.flags &
(EFL_IF|V86_IF_PENDING))
== 0)
-   state->efl &= ~EFL_IF;
+   saved_state->efl &= ~EFL_IF;
}
}
else {
diff --git a/i386/include/mach/i386/thread_status.h 
b/i386/include/mach/i386/thread_status.h
index 2d05947e..3de22ff3 100644
--- a/i386/include/mach/i386/thread_status.h
+++ b/i386/include/mach/i386/thread_status.h
@@ -100,7 +100,7 @@ struct i386_thread_state {
 
unsigned intcs;
 #if defined(__x86_64__) && !defined(USER32)
-   uint64_tefl;
+   uint64_trfl;
uint64_tursp;
 #else
unsigned intefl;
-- 
2.39.1

Re: [PATCH gnumach] Add x86_64 registers to i386_thread_state

[Flávio Cruz]

On Tue, Feb 14, 2023 at 2:51 PM Samuel Thibault 
wrote:

> Sergey Bugaev, le mar. 14 févr. 2023 22:48:18 +0300, a ecrit:
> > On Tue, Feb 14, 2023 at 10:20 PM Samuel Thibault
> >  wrote:
> > > > > +#if defined(__x86_64__) && !defined(USER32)
> > > > > +   uint64_tefl;
> > > >
> > > > Should this not be 'rfl' (for 'rflags')?
> > >
> > > In both cases, that would make the gnumach code have to distinguish the
> > > two names, in the debugger and various other places.
> >
> > Yes,
>
> Sorry, I got back to this mail and confused my first and second reading,
> then mistaking your sentence for the internal structure.
>
> What I said is only concerning the internal structure.
>
> For this efl flag, I don't have any idea why flavio let it as efl.
>

No strong reason, I was just trying to avoid touching the code below that
also relies on this field, but I think it makes sense
to have a clean public interface.


> Samuel
>

Re: [PATCH gnumach] Add x86_64 registers to i386_thread_state

[Samuel Thibault]

Sergey Bugaev, le mar. 14 févr. 2023 22:48:18 +0300, a ecrit:
> On Tue, Feb 14, 2023 at 10:20 PM Samuel Thibault
>  wrote:
> > > > +#if defined(__x86_64__) && !defined(USER32)
> > > > +   uint64_tefl;
> > >
> > > Should this not be 'rfl' (for 'rflags')?
> >
> > In both cases, that would make the gnumach code have to distinguish the
> > two names, in the debugger and various other places.
> 
> Yes,

Sorry, I got back to this mail and confused my first and second reading,
then mistaking your sentence for the internal structure.

What I said is only concerning the internal structure.

For this efl flag, I don't have any idea why flavio let it as efl.

Samuel

Re: [PATCH gnumach] Add x86_64 registers to i386_thread_state

[Sergey Bugaev]

On Tue, Feb 14, 2023 at 10:20 PM Samuel Thibault
 wrote:
> > > +#if defined(__x86_64__) && !defined(USER32)
> > > +   uint64_tefl;
> >
> > Should this not be 'rfl' (for 'rflags')?
>
> In both cases, that would make the gnumach code have to distinguish the
> two names, in the debugger and various other places.

Yes, but that is already the case for every other register that
existed as exxx on x86 and got extended to rxxx in amd64. This same
patch already replaces esi -> rsi, eip -> rip, eax -> rax etc. Why
single out eflags?

Sergey

Re: [PATCH 2/3] mach: undef ENTRY2

[Samuel Thibault]

Applied, thanks!

Sergey Bugaev via Libc-alpha, le mar. 14 févr. 2023 20:37:21 +0300, a ecrit:
> This macro from Mach headers conflicts with how
> sysdeps/x86_64/multiarch/strcmp-sse2.S expects it to be defined.
> 
> Signed-off-by: Sergey Bugaev 
> ---
>  sysdeps/mach/sysdep.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/sysdeps/mach/sysdep.h b/sysdeps/mach/sysdep.h
> index fe26bcb3..1c869f5c 100644
> --- a/sysdeps/mach/sysdep.h
> +++ b/sysdeps/mach/sysdep.h
> @@ -30,6 +30,7 @@
>  /* For ELF we need to add the `.type' directive to make shared libraries
> work right.  */
>  #undef ENTRY
> +#undef ENTRY2
>  #define ENTRY(name) \
>.globl name; \
>.align ALIGN; \
> -- 
> 2.39.1
> 

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

Re: [PATCH 1/3] hurd: i386 TLS tweaks

[Samuel Thibault]

Applied, thanks!

Sergey Bugaev via Libc-alpha, le mar. 14 févr. 2023 20:37:20 +0300, a ecrit:
> * Micro-optimize TLS access using GCC's native support for gs-based
>   addressing when available;
> * Just use THREAD_GETMEM and THREAD_SETMEM instead of more inline
>   assembly;
> * Sync tcbhead_t layout with NPTL, in particular update/fix __private_ss
>   offset;
> * Statically assert that the two offsets that are a part of ABI are what
>   we expect them to be.
> 
> Signed-off-by: Sergey Bugaev 
> ---
>  sysdeps/mach/hurd/i386/tls.h | 48 ++--
>  1 file changed, 35 insertions(+), 13 deletions(-)
> 
> diff --git a/sysdeps/mach/hurd/i386/tls.h b/sysdeps/mach/hurd/i386/tls.h
> index a6ff0107..dc43d4c7 100644
> --- a/sysdeps/mach/hurd/i386/tls.h
> +++ b/sysdeps/mach/hurd/i386/tls.h
> @@ -38,11 +38,12 @@ typedef struct
>uintptr_t stack_guard;
>uintptr_t pointer_guard;
>int gscope_flag;
> -  int private_futex;
> +  unsigned int feature_1;
>/* Reservation of some values for the TM ABI.  */
> -  void *__private_tm[4];
> +  void *__private_tm[3];
>/* GCC split stack support.  */
>void *__private_ss;
> +  void *__glibc_padding1;
>  
>/* Keep these fields last, so offsets of fields above can continue being
>   compatible with the i386 Linux version.  */
> @@ -53,6 +54,13 @@ typedef struct
>struct rtld_catch *rtld_catch;
>  } tcbhead_t;
>  
> +/* GCC generates %gs:0x14 to access the stack guard.  */
> +_Static_assert (offsetof (tcbhead_t, stack_guard) == 0x14,
> +"stack guard offset");
> +/* libgcc uses %gs:0x30 to access the split stack pointer.  */
> +_Static_assert (offsetof (tcbhead_t, __private_ss) == 0x30,
> +"split stack pointer offset");
> +
>  /* Return tcbhead_t from a TLS segment descriptor.  */
>  # define HURD_DESC_TLS(desc)   \
>({   \
> @@ -166,8 +174,25 @@ out:
>  # define TLS_INIT_TP(descr) \
>  _hurd_tls_init ((tcbhead_t *) (descr))
>  
> +# if __GNUC_PREREQ (6, 0)
> +
> +#  define THREAD_SELF
>   \
> +  (*(tcbhead_t * __seg_gs *) offsetof (tcbhead_t, tcb))
> +#  define THREAD_GETMEM(descr, member)   
>   \
> +  (*(__typeof (descr->member) __seg_gs *) offsetof (tcbhead_t, member))
> +#  define THREAD_GETMEM_NC(descr, member, idx)   
>   \
> +  (*(__typeof (descr->member[0]) __seg_gs *)   \
> +   (offsetof (tcbhead_t, member) + (idx) * sizeof (descr->member[0])))
> +#  define THREAD_SETMEM(descr, member, value)
>   \
> +  (*(__typeof (descr->member) __seg_gs *) offsetof (tcbhead_t, member) = 
> value)
> +#  define THREAD_SETMEM_NC(descr, member, index, value)  
>   \
> +  (*(__typeof (descr->member[0]) __seg_gs *)   \
> +   (offsetof (tcbhead_t, member) + (idx) * sizeof (descr->member[0])))
> +
> +# else
> +
>  /* Return the TCB address of the current thread.  */
> -# define THREAD_SELF   \
> +#  define THREAD_SELF
>   \
>({ tcbhead_t *__tcb;   
>   \
>   __asm__ ("movl %%gs:%c1,%0" : "=r" (__tcb)  
>   \
> : "i" (offsetof (tcbhead_t, tcb))); \
> @@ -200,7 +225,7 @@ out:
>  
>  
>  /* Same as THREAD_GETMEM, but the member offset can be non-constant.  */
> -# define THREAD_GETMEM_NC(descr, member, idx) \
> +#  define THREAD_GETMEM_NC(descr, member, idx) \
>({ __typeof (descr->member[0]) __value;  \
>   _Static_assert (sizeof (__value) == 1 \
>|| sizeof (__value) == 4 \
> @@ -229,7 +254,7 @@ out:
>  
>  
>  /* Set member of the thread descriptor directly.  */
> -# define THREAD_SETMEM(descr, member, value) \
> +#  define THREAD_SETMEM(descr, member, value) \
>({   \
>   _Static_assert (sizeof (descr->member) == 1   \
>|| sizeof (descr->member) == 4   \
> @@ -254,7 +279,7 @@ out:
>  
>  
>  /* Same as THREAD_SETMEM, but the member offset can be non-constant.  */
> -# define THREAD_SETMEM_NC(descr, member, idx, value) \
> +#  define THREAD_SETMEM_NC(descr, member, idx, value) \
>({   \
>   _Static_assert (sizeof (descr->member[0]) == 1\
>|| sizeof (descr->member[0]) == 4\
> @@ -279,6 +304,8 @@ out:

Re: [PATCH gnumach] Add x86_64 registers to i386_thread_state

[Samuel Thibault]

Hello,

Sergey Bugaev, le mar. 14 févr. 2023 14:03:22 +0300, a ecrit:
> On Sun, Feb 12, 2023 at 9:26 PM Flavio Cruz  wrote:
> >
> > This is required to implement ptrace.
> > ---
> >  i386/i386/pcb.c| 42 +-
> >  i386/include/mach/i386/thread_status.h | 28 +
> >  2 files changed, 69 insertions(+), 1 deletion(-)
> >
> > diff --git a/i386/i386/pcb.c b/i386/i386/pcb.c
> > index 9ac55a1c..ba856523 100644
> > --- a/i386/i386/pcb.c
> > +++ b/i386/i386/pcb.c
> > @@ -500,6 +500,25 @@ kern_return_t thread_setstatus(
> > /*
> >  * General registers
> >  */
> > +#if defined(__x86_64__) && !defined(USER32)
> > +   saved_state->r8 = state->r8;
> > +   saved_state->r9 = state->r9;
> > +   saved_state->r10 = state->r10;
> > +   saved_state->r11 = state->r11;
> > +   saved_state->r12 = state->r12;
> > +   saved_state->r13 = state->r13;
> > +   saved_state->r14 = state->r14;
> > +   saved_state->r15 = state->r15;
> > +   saved_state->edi = state->rdi;
> > +   saved_state->esi = state->rsi;
> > +   saved_state->ebp = state->rbp;
> > +   saved_state->uesp = state->ursp;
> > +   saved_state->ebx = state->rbx;
> > +   saved_state->edx = state->rdx;
> > +   saved_state->ecx = state->rcx;
> > +   saved_state->eax = state->rax;
> > +   saved_state->eip = state->rip;
> 
> Do I understand correctly that the names of the i386_saved_state
> registers are not updated for x86_64 because it's an internal header,
> whereas i386_thread_state is public and it has to look right?

For an internal header we can do whatever we prefer indeed, while for a
public header we better use proper names.

> Still, I would find it cleaner / less surprising if both structures
> were updated the same way.
> 
> > +#if defined(__x86_64__) && !defined(USER32)
> > +   uint64_tefl;
> 
> Should this not be 'rfl' (for 'rflags')?

In both cases, that would make the gnumach code have to distinguish the
two names, in the debugger and various other places.

Samuel

[PATCH 1/3] hurd: i386 TLS tweaks

[Sergey Bugaev]

* Micro-optimize TLS access using GCC's native support for gs-based
  addressing when available;
* Just use THREAD_GETMEM and THREAD_SETMEM instead of more inline
  assembly;
* Sync tcbhead_t layout with NPTL, in particular update/fix __private_ss
  offset;
* Statically assert that the two offsets that are a part of ABI are what
  we expect them to be.

Signed-off-by: Sergey Bugaev 
---
 sysdeps/mach/hurd/i386/tls.h | 48 ++--
 1 file changed, 35 insertions(+), 13 deletions(-)

diff --git a/sysdeps/mach/hurd/i386/tls.h b/sysdeps/mach/hurd/i386/tls.h
index a6ff0107..dc43d4c7 100644
--- a/sysdeps/mach/hurd/i386/tls.h
+++ b/sysdeps/mach/hurd/i386/tls.h
@@ -38,11 +38,12 @@ typedef struct
   uintptr_t stack_guard;
   uintptr_t pointer_guard;
   int gscope_flag;
-  int private_futex;
+  unsigned int feature_1;
   /* Reservation of some values for the TM ABI.  */
-  void *__private_tm[4];
+  void *__private_tm[3];
   /* GCC split stack support.  */
   void *__private_ss;
+  void *__glibc_padding1;
 
   /* Keep these fields last, so offsets of fields above can continue being
  compatible with the i386 Linux version.  */
@@ -53,6 +54,13 @@ typedef struct
   struct rtld_catch *rtld_catch;
 } tcbhead_t;
 
+/* GCC generates %gs:0x14 to access the stack guard.  */
+_Static_assert (offsetof (tcbhead_t, stack_guard) == 0x14,
+"stack guard offset");
+/* libgcc uses %gs:0x30 to access the split stack pointer.  */
+_Static_assert (offsetof (tcbhead_t, __private_ss) == 0x30,
+"split stack pointer offset");
+
 /* Return tcbhead_t from a TLS segment descriptor.  */
 # define HURD_DESC_TLS(desc) \
   ({ \
@@ -166,8 +174,25 @@ out:
 # define TLS_INIT_TP(descr) \
 _hurd_tls_init ((tcbhead_t *) (descr))
 
+# if __GNUC_PREREQ (6, 0)
+
+#  define THREAD_SELF\
+  (*(tcbhead_t * __seg_gs *) offsetof (tcbhead_t, tcb))
+#  define THREAD_GETMEM(descr, member)   \
+  (*(__typeof (descr->member) __seg_gs *) offsetof (tcbhead_t, member))
+#  define THREAD_GETMEM_NC(descr, member, idx)   \
+  (*(__typeof (descr->member[0]) __seg_gs *) \
+   (offsetof (tcbhead_t, member) + (idx) * sizeof (descr->member[0])))
+#  define THREAD_SETMEM(descr, member, value)\
+  (*(__typeof (descr->member) __seg_gs *) offsetof (tcbhead_t, member) = value)
+#  define THREAD_SETMEM_NC(descr, member, index, value)
  \
+  (*(__typeof (descr->member[0]) __seg_gs *) \
+   (offsetof (tcbhead_t, member) + (idx) * sizeof (descr->member[0])))
+
+# else
+
 /* Return the TCB address of the current thread.  */
-# define THREAD_SELF \
+#  define THREAD_SELF\
   ({ tcbhead_t *__tcb;   \
  __asm__ ("movl %%gs:%c1,%0" : "=r" (__tcb)
  \
  : "i" (offsetof (tcbhead_t, tcb))); \
@@ -200,7 +225,7 @@ out:
 
 
 /* Same as THREAD_GETMEM, but the member offset can be non-constant.  */
-# define THREAD_GETMEM_NC(descr, member, idx) \
+#  define THREAD_GETMEM_NC(descr, member, idx) \
   ({ __typeof (descr->member[0]) __value;\
  _Static_assert (sizeof (__value) == 1   \
 || sizeof (__value) == 4 \
@@ -229,7 +254,7 @@ out:
 
 
 /* Set member of the thread descriptor directly.  */
-# define THREAD_SETMEM(descr, member, value) \
+#  define THREAD_SETMEM(descr, member, value) \
   ({ \
  _Static_assert (sizeof (descr->member) == 1 \
 || sizeof (descr->member) == 4   \
@@ -254,7 +279,7 @@ out:
 
 
 /* Same as THREAD_SETMEM, but the member offset can be non-constant.  */
-# define THREAD_SETMEM_NC(descr, member, idx, value) \
+#  define THREAD_SETMEM_NC(descr, member, idx, value) \
   ({ \
  _Static_assert (sizeof (descr->member[0]) == 1  \
 || sizeof (descr->member[0]) == 4\
@@ -279,6 +304,8 @@ out:
 "r" (idx));  \
}})
 
+# endif /* __GNUC_PREREQ (6, 0) */
+
 /* Return the TCB address of a thread given its state.
Note: this is expensive.  */
 # define THREAD_TCB(thread, thread_state)\
@@ -295,15 +322,10 @@ 

[PATCH 3/3] htl: Make pthread_mutex_t pointer-aligned

[Sergey Bugaev]

This is for future-proofing. On i386, it is 4-byte aligned anyway, but
on x86_64, we want it 8-byte aligned, not 4-byte aligned.

Signed-off-by: Sergey Bugaev 
---
 .../hurd/htl/bits/types/struct___pthread_mutex.h| 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/sysdeps/mach/hurd/htl/bits/types/struct___pthread_mutex.h 
b/sysdeps/mach/hurd/htl/bits/types/struct___pthread_mutex.h
index d7b239f4..11caa870 100644
--- a/sysdeps/mach/hurd/htl/bits/types/struct___pthread_mutex.h
+++ b/sysdeps/mach/hurd/htl/bits/types/struct___pthread_mutex.h
@@ -30,20 +30,23 @@ struct __pthread_mutex
   int __shpid;
   int __type;
   int __flags;
-  unsigned int __reserved1;
-  unsigned int __reserved2;
+  union
+  {
+unsigned int __reserved[2];
+void *__pointer_aligned;
+  };
 };
 
 /* Static mutex initializers. */
 #define __PTHREAD_MUTEX_INITIALIZER   \
-  { 0, 0, 0, 0, __PTHREAD_MUTEX_TIMED, 0, 0, 0 }
+  { 0, 0, 0, 0, __PTHREAD_MUTEX_TIMED, 0, { { 0, 0 } } }
 
 /* The +1 is to mantain binary compatibility with the old
  * libpthread implementation. */
 #define __PTHREAD_ERRORCHECK_MUTEX_INITIALIZER   \
-  { 0, 0, 0, 0, __PTHREAD_MUTEX_ERRORCHECK + 1, 0, 0, 0 }
+  { 0, 0, 0, 0, __PTHREAD_MUTEX_ERRORCHECK + 1, 0, { { 0, 0 } } }
 
 #define __PTHREAD_RECURSIVE_MUTEX_INITIALIZER   \
-  { 0, 0, 0, 0, __PTHREAD_MUTEX_RECURSIVE + 1, 0, 0, 0 }
+  { 0, 0, 0, 0, __PTHREAD_MUTEX_RECURSIVE + 1, 0, { { 0, 0 } } }
 
 #endif /* bits/types/struct___pthread_mutex.h */
-- 
2.39.1

[PATCH 0/3] x86_64-gnu follow-ups

[Sergey Bugaev]

* Port the TLS improvements back to i386
* Sneak in another x86_64 fix
* Attempt to make mutexes pointer-aligned

That last one is sort of ugly with how the initializers grew two pairs of
braces, but it seems to build. Maybe it would be better to try with
__attribute__ ((__aligned__ (sizeof (void * instead?

Sergey Bugaev (3):
  hurd: i386 TLS tweaks
  mach: undef ENTRY2
  htl: Make pthread_mutex_t pointer-aligned

 .../htl/bits/types/struct___pthread_mutex.h   | 13 +++--
 sysdeps/mach/hurd/i386/tls.h  | 48 ++-
 sysdeps/mach/sysdep.h |  1 +
 3 files changed, 44 insertions(+), 18 deletions(-)

-- 
2.39.1

[PATCH 2/3] mach: undef ENTRY2

[Sergey Bugaev]

This macro from Mach headers conflicts with how
sysdeps/x86_64/multiarch/strcmp-sse2.S expects it to be defined.

Signed-off-by: Sergey Bugaev 
---
 sysdeps/mach/sysdep.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sysdeps/mach/sysdep.h b/sysdeps/mach/sysdep.h
index fe26bcb3..1c869f5c 100644
--- a/sysdeps/mach/sysdep.h
+++ b/sysdeps/mach/sysdep.h
@@ -30,6 +30,7 @@
 /* For ELF we need to add the `.type' directive to make shared libraries
work right.  */
 #undef ENTRY
+#undef ENTRY2
 #define ENTRY(name) \
   .globl name; \
   .align ALIGN; \
-- 
2.39.1

checking whether mig supports the retcode keyword... no

[Sergey Bugaev]

This line in configure logs has always bugged me; of course GNU MIG
supports "retcode" (as in, does not report an error upon seeing it).
Today I happened to have journalctl -f opened at the time I ran
../configure, and accidentally found out why this happens:

kernel: traps: x86_64-gnu-migc[177175] trap divide error ip:40befb
sp:7ffc84726920 error:0 in x86_64-gnu-migcom[401000+1]

oh noes!

$ coredumpctl debug

Core was generated by
`/home/sergey/dev/crosshurd64/bin/../libexec/x86_64-gnu-migcom -n'.
Program terminated with signal SIGFPE, Arithmetic exception.
#0  0x0040befb in itVarArrayDecl (number=0, old=0xb285e0) at
../type.c:632
632 it->itNumber = (2048 / bytes) * it->itNumber;
(gdb) bt
#0  0x0040befb in itVarArrayDecl (number=0, old=0xb285e0) at
../type.c:632
#1  0x004059ef in yyparse () at ../parser.y:474
#2  0x004012c9 in main (argc=, argv=) at ../migcom.c:218
(gdb) p bytes
$1 = 0
(gdb) p *old
$2 = {itName = 0x0, itNext = 0x0, itTypeSize = 0, itPadSize = 0,
itMinTypeSize = 0, itAlignment = 0, itInName = 0, itOutName = 0,
itSize = 0, itNumber = 1, itInLine = true, itLongForm = false,
  itDeallocate = d_NO, itInNameStr = 0x0, itOutNameStr = 0x0, itFlags
= 0, itStruct = true, itString = false, itVarArray = false,
itIndefinite = false, itKernelPort = false, itElement = 0x0,
  itUserType = 0x0, itServerType = 0x0, itTransType = 0x0, itInTrans =
0x0, itInTransPayload = 0x0, itOutTrans = 0x0, itDestructor = 0x0}

That type doesn't look right! But then I looked at the configure log
and found this:

configure:4633: checking whether x86_64-gnu-mig supports the retcode keyword
configure:4650: CC=x86_64-gnu-gcc x86_64-gnu-mig -n conftest.defs 1>&5
"/home/sergey/dev/crosshurd64/include/mach/std_types.defs", line 32:
Basic types not initialized when looking up type int32_t. Did you
forget to define the subsystem?
"/home/sergey/dev/crosshurd64/include/mach/std_types.defs", line 33:
Basic types not initialized when looking up type int64_t. Did you
forget to define the subsystem?
"/home/sergey/dev/crosshurd64/include/mach/std_types.defs", line 34:
Basic types not initialized when looking up type boolean_t. Did you
forget to define the subsystem?
"/home/sergey/dev/crosshurd64/include/mach/std_types.defs", line 35:
Basic types not initialized when looking up type unsigned. Did you
forget to define the subsystem?
"/home/sergey/dev/crosshurd64/include/mach/std_types.defs", line 36:
Basic types not initialized when looking up type uint32_t. Did you
forget to define the subsystem?
"/home/sergey/dev/crosshurd64/include/mach/std_types.defs", line 37:
Basic types not initialized when looking up type uint64_t. Did you
forget to define the subsystem?
"/home/sergey/dev/crosshurd64/include/mach/x86_64/machine_types.defs",
line 45: Basic types not initialized when looking up type uint32_t.
Did you forget to define the subsystem?
"/home/sergey/dev/crosshurd64/include/mach/x86_64/machine_types.defs",
line 45: type 'uint32_t' not defined
"/home/sergey/dev/crosshurd64/include/mach/x86_64/machine_types.defs",
line 45: Basic types not initialized when looking up type natural_t.
Did you forget to define the subsystem?
"/home/sergey/dev/crosshurd64/include/mach/x86_64/machine_types.defs",
line 54: Basic types not initialized when looking up type int32_t. Did
you forget to define the subsystem?
"/home/sergey/dev/crosshurd64/include/mach/x86_64/machine_types.defs",
line 54: type 'int32_t' not defined
"/home/sergey/dev/crosshurd64/include/mach/x86_64/machine_types.defs",
line 54: Basic types not initialized when looking up type integer_t.
Did you forget to define the subsystem?
"/home/sergey/dev/crosshurd64/include/mach/x86_64/machine_types.defs",
line 65: Basic types not initialized when looking up type uint64_t.
Did you forget to define the subsystem?
"/home/sergey/dev/crosshurd64/include/mach/x86_64/machine_types.defs",
line 65: type 'uint64_t' not defined
"/home/sergey/dev/crosshurd64/include/mach/x86_64/machine_types.defs",
line 65: Basic types not initialized when looking up type
rpc_long_natural_t. Did you forget to define the subsystem?
"/home/sergey/dev/crosshurd64/include/mach/x86_64/machine_types.defs",
line 66: Basic types not initialized when looking up type int64_t. Did
you forget to define the subsystem?
"/home/sergey/dev/crosshurd64/include/mach/x86_64/machine_types.defs",
line 66: type 'int64_t' not defined
"/home/sergey/dev/crosshurd64/include/mach/x86_64/machine_types.defs",
line 66: Basic types not initialized when looking up type
rpc_long_integer_t. Did you forget to define the subsystem?
"/home/sergey/dev/crosshurd64/include/mach/x86_64/machine_types.defs",
line 78: Basic types not initialized when looking up type
rpc_long_natural_t. Did you forget to define the subsystem?
"/home/sergey/dev/crosshurd64/include/mach/x86_64/machine_types.defs",
line 78: type 'rpc_long_natural_t' not defined
"/home/sergey/dev/crosshurd64/include/mach/x86_64/machine_types.defs",
line 85: 

[sr #110199] Cross-building of GNU/Hurd and additional packages

[Svante Signell]

Follow-up Comment #35, sr #110199 (project administration):

Hi again,

The file COPYING in patches/PAM/hurd_no_setfsuid.diff was added by me. The
text in that file is now changed to:
Copyright (C) 2018 Steve Langasek. Linux-PAM is free software licensed under
the 3-clause BSD license, see the file ../../licenses/BSD-3. Is that better?

Any other issues with licences and copyright?

Thanks!


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

Re: [PATCH gnumach] Add x86_64 registers to i386_thread_state

[Sergey Bugaev]

On Sun, Feb 12, 2023 at 9:26 PM Flavio Cruz  wrote:
>
> This is required to implement ptrace.
> ---
>  i386/i386/pcb.c| 42 +-
>  i386/include/mach/i386/thread_status.h | 28 +
>  2 files changed, 69 insertions(+), 1 deletion(-)
>
> diff --git a/i386/i386/pcb.c b/i386/i386/pcb.c
> index 9ac55a1c..ba856523 100644
> --- a/i386/i386/pcb.c
> +++ b/i386/i386/pcb.c
> @@ -500,6 +500,25 @@ kern_return_t thread_setstatus(
> /*
>  * General registers
>  */
> +#if defined(__x86_64__) && !defined(USER32)
> +   saved_state->r8 = state->r8;
> +   saved_state->r9 = state->r9;
> +   saved_state->r10 = state->r10;
> +   saved_state->r11 = state->r11;
> +   saved_state->r12 = state->r12;
> +   saved_state->r13 = state->r13;
> +   saved_state->r14 = state->r14;
> +   saved_state->r15 = state->r15;
> +   saved_state->edi = state->rdi;
> +   saved_state->esi = state->rsi;
> +   saved_state->ebp = state->rbp;
> +   saved_state->uesp = state->ursp;
> +   saved_state->ebx = state->rbx;
> +   saved_state->edx = state->rdx;
> +   saved_state->ecx = state->rcx;
> +   saved_state->eax = state->rax;
> +   saved_state->eip = state->rip;

Do I understand correctly that the names of the i386_saved_state
registers are not updated for x86_64 because it's an internal header,
whereas i386_thread_state is public and it has to look right? Still, I
would find it cleaner / less surprising if both structures were
updated the same way.

> @@ -76,9 +96,17 @@ struct i386_thread_state {
> unsigned intecx;
> unsigned inteax;
> unsigned inteip;
> +#endif  /* __x86_64__ && !USER32 */
> +
> unsigned intcs;
> +#if defined(__x86_64__) && !defined(USER32)
> +   uint64_tefl;

Should this not be 'rfl' (for 'rflags')?

Sergey