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
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
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
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
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.)
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
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
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
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
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
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?
11 matches
Mail list logo