Re: [PATCH gnumach] Align the user stack correctly for 64 bit programs.

2023-04-03 Thread Samuel Thibault
Applied, thanks! Flavio Cruz, le dim. 02 avril 2023 23:56:31 -0400, a ecrit: > * i386/i386/thread.h: Define USER_STACK_ALIGN which is 16-byte for 64 bit > programs as recommended by the System V AMD64 guidelines. Also define > KERNEL_STACK_ALIGN which can differ from user land. > * i386/i386/p

Re: [RFC PATCH glibc 13/34] x86-64: Disable prefer_map_32bit_exec tunable on non-Linux

2023-04-03 Thread Sergey Bugaev
On Mon, Apr 3, 2023 at 10:02 PM H.J. Lu wrote: > Or something like this. Or like that, yeah! On a second thought, I actually like Samuel's idea (ifdef MAP_32BIT): instead of only building this piece of code when the tunable *is* defined, we'd build it when the tunable *should be* defined (that i

Re: [RFC PATCH glibc 13/34] x86-64: Disable prefer_map_32bit_exec tunable on non-Linux

2023-04-03 Thread H.J. Lu
On Mon, Apr 3, 2023 at 3:10 AM Sergey Bugaev wrote: > > On Mon, Apr 3, 2023 at 2:09 AM Samuel Thibault > wrote: > > Sergey Bugaev, le dim. 19 mars 2023 18:09:56 +0300, a ecrit: > > > While we could/should implement MAP_32BIT for the Hurd port by setting > > > all the high bits of mask in a vm_ma

[PATCH v2 18.2/34] hurd: Port trampoline.c to x86_64

2023-04-03 Thread Sergey Bugaev
Signed-off-by: Sergey Bugaev --- sysdeps/mach/hurd/{i386 => x86}/trampoline.c | 158 ++- 1 file changed, 151 insertions(+), 7 deletions(-) rename sysdeps/mach/hurd/{i386 => x86}/trampoline.c (68%) diff --git a/sysdeps/mach/hurd/i386/trampoline.c b/sysdeps/mach/hurd/x86/trampoli

[PATCH v2 18.0/34] Alignment-respecting x86_64 trampoline.c

2023-04-03 Thread Sergey Bugaev
And here's another attempt at trampoline.c, this time hopefully with properly aligned stack on both the user's signal handler call and the __sigreturn call. (Split across two patches and this tiny cover letter, hopefully not too confusing.)

[PATCH v2 18.1/34] hurd: Do not declare local variables volatile

2023-04-03 Thread Sergey Bugaev
These are just regular local variables that are not accessed in any funny ways, not even though a pointer. There's absolutely no reason to declare them volatile. It only ends up hurting the quality of the generated machine code. If anything, it would make sense to decalre sigsp as *pointing* to vo

[PATCH v2] hurd: Implement sigreturn for x86_64

2023-04-03 Thread Sergey Bugaev
Here's a better version that does not do the stupid __builtin_frame_address thing (instead, we call the function for real, and pass usp as an arg), and should actually ensure the 16-byte alignment. -- >8 -- Signed-off-by: Sergey Bugaev --- sysdeps/mach/hurd/x86_64/sigreturn.c | 151

Re: [RFC PATCH glibc 13/34] x86-64: Disable prefer_map_32bit_exec tunable on non-Linux

2023-04-03 Thread Sergey Bugaev
On Mon, Apr 3, 2023 at 2:09 AM Samuel Thibault wrote: > Sergey Bugaev, le dim. 19 mars 2023 18:09:56 +0300, a ecrit: > > While we could/should implement MAP_32BIT for the Hurd port by setting > > all the high bits of mask in a vm_map () call, neither MAP_32BIT nor > > glibc.cpu.prefer_map_32bit_ex

Re: [RFC PATCH gnumach 02/34] Remove bootstrap.defs

2023-04-03 Thread Sergey Bugaev
On Mon, Apr 3, 2023 at 1:43 AM Samuel Thibault wrote: > I guess the do_bootstrap_privileged_ports function can be dropped from > the hurd repo? I think so, yes, along with the #include "bootstrap_S.h". boot.c never calls the bootstrap_server_routine, so it's all unused anyway. Sergey

Re: [RFC PATCH gnumach 03/34] Make exception subcode a long

2023-04-03 Thread Sergey Bugaev
On Mon, Apr 3, 2023 at 1:45 AM Samuel Thibault wrote: > Sergey Bugaev, le dim. 19 mars 2023 18:09:46 +0300, a ecrit: > > On EXC_BAD_ACCESS, exception subcode is used to pass the faulting memory > > address, so it needs to be (at least) pointer-sized. Thus, make it into > > a long. > > > > This req

Re: [RFC PATCH glibc 23/34] elf: Stop including tls.h in ldsodefs.h

2023-04-03 Thread Sergey Bugaev
On Mon, Apr 3, 2023 at 2:20 AM Samuel Thibault wrote: > Sergey Bugaev, le dim. 19 mars 2023 18:10:06 +0300, a ecrit: > > Nothing in there needs tls.h > > Ok but includers might be erroneously relying on it. Did you try to > build various configurations, to make sure that this isn't breaking any?