[RFC PATCH 2/9] hurd: Use proper integer types

Fix a few more cases of build errors caused by mismatched types. This is a continuation of f4315054b46d5e58b44a709a51943fb73f846afb. Signed-off-by: Sergey Bugaev --- hurd/hurdsig.c | 6 +++--- sysdeps/mach/hurd/getpriority.c | 6 +++--- sysdeps/mach/hurd/if_index.c| 2

[RFC PATCH 1/9] hurd: Move thread state manipulation into _hurd_tls_new ()

This is going to be done differently on x86_64. Signed-off-by: Sergey Bugaev --- mach/setup-thread.c | 18 ++ sysdeps/mach/hurd/i386/tls.h | 25 - 2 files changed, 22 insertions(+), 21 deletions(-) diff --git a/mach/setup-thread.c b/mach/setup

[RFC PATCH 3/9] hurd: Fix xattr function return type

They all return int, not size_t. Signed-off-by: Sergey Bugaev --- sysdeps/mach/hurd/fsetxattr.c| 2 +- sysdeps/mach/hurd/lremovexattr.c | 2 +- sysdeps/mach/hurd/lsetxattr.c| 2 +- sysdeps/mach/hurd/removexattr.c | 2 +- sysdeps/mach/hurd/setxattr.c | 2 +- 5 files changed, 5

[RFC PATCH 6/9] mach: Use PAGE_SIZE

p of every process! Signed-off-by: Sergey Bugaev --- mach/mach_init.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/mach/mach_init.c b/mach/mach_init.c index a0d9f7f5..42b9cacf 100644 --- a/mach/mach_init.c +++ b/mach/mach_init.c @@ -17,6 +17,7 @@ #include

[RFC PATCH 8/9 gnumach] Add i386_fsgs_base_state

--- i386/include/mach/i386/thread_status.h | 8 1 file changed, 8 insertions(+) diff --git a/i386/include/mach/i386/thread_status.h b/i386/include/mach/i386/thread_status.h index 3de22ff3..32e40686 100644 --- a/i386/include/mach/i386/thread_status.h +++ b/i386/include/mach/i386/thread_s

[RFC PATCH 9/9] hurd, htl: Add some more x86_64-specific code

Signed-off-by: Sergey Bugaev --- sysdeps/mach/hurd/x86/init-first.c | 14 +- sysdeps/mach/hurd/x86_64/tls.h | 257 sysdeps/mach/x86_64/thread_state.h | 51 sysdeps/x86_64/htl/bits/pthreadtypes-arch.h | 36 +++ sysdeps/x86_64/htl/pt

[RFC PATCH 4/9] hurd: Make timer_t pointer-sized

This ensures that a timer_t value can be cast to struct timer_node * and back. Signed-off-by: Sergey Bugaev --- sysdeps/mach/hurd/bits/typesizes.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sysdeps/mach/hurd/bits/typesizes.h b/sysdeps/mach/hurd/bits/typesizes.h index

Re: [RFC PATCH 8/9 gnumach] Add i386_fsgs_base_state

On Sun, Feb 19, 2023 at 12:34 AM Luca wrote: > > Hi! > > Il 18/02/23 21:37, Sergey Bugaev ha scritto: > > +struct i386_fsgs_base_state { > > + unsigned long fs_base; > > + unsigned long gs_base; > > +}; > > The fs and gs registers are also set by

Re: [RFC PATCH 7/9] hurd: Generalize init-first.c to support x86_64

On Mon, Feb 20, 2023 at 3:01 AM Samuel Thibault wrote: > That won't work on x86_64: there, arguments are passed mostly through > registers, so &argc won't actually give you the address of arguments on > the stack. Right, good point. I wish I had a better understanding of just what's going on in

Re: [RFC PATCH 7/9] hurd: Generalize init-first.c to support x86_64

> I wish I had a better understanding of just what's going on in this > file. Maybe a lot of the hacks can be rewritten in a nicer way. For > instance, do we really need to hijack the return addresses and jump to > init1 in this weird way, only to enable it to access argc/arg0? Since > we know wher

[PATCH v2 1/4] hurd: Simplify init-first.c further

This drops all of the return address rewriting kludges. The only remaining hack is the jump out of a call stack while adjusting the stack pointer. Signed-off-by: Sergey Bugaev --- sysdeps/mach/hurd/dl-sysdep.c | 5 +- sysdeps/mach/hurd/i386/dl-machine.h | 7 - sysdeps/mach/hurd/i386

[PATCH v2 0/4] More x86_64-gnu glibc work

hed patches I'm carrying locally are "htl: Make pthread_mutex_t pointer-aligned" and the mach-machine part of "mach: Look for mach_i386.defs on x86_64 too". You may need to apply them to actually build any of this on x86_64. Sergey Bugaev (4): hurd: Simplify init-first.c f

[PATCH v2 2/4] hurd: Generalize init-first.c to support x86_64

Signed-off-by: Sergey Bugaev --- sysdeps/mach/hurd/{i386 => x86}/init-first.c | 6 ++ 1 file changed, 6 insertions(+) rename sysdeps/mach/hurd/{i386 => x86}/init-first.c (97%) diff --git a/sysdeps/mach/hurd/i386/init-first.c b/sysdeps/mach/hurd/x86/init-first.c similarity index 97%

[PATCH v2 3/4] hurd: Implement TLS for x86_64

Signed-off-by: Sergey Bugaev --- sysdeps/mach/hurd/x86/init-first.c | 14 +- sysdeps/mach/hurd/x86_64/tls.h | 215 + 2 files changed, 228 insertions(+), 1 deletion(-) create mode 100644 sysdeps/mach/hurd/x86_64/tls.h diff --git a/sysdeps/mach/hurd/x86/init

[PATCH v2 4/4] htl: Add pthreadtypes-arch.h for x86_64

Signed-off-by: Sergey Bugaev --- sysdeps/x86_64/htl/bits/pthreadtypes-arch.h | 36 + 1 file changed, 36 insertions(+) create mode 100644 sysdeps/x86_64/htl/bits/pthreadtypes-arch.h diff --git a/sysdeps/x86_64/htl/bits/pthreadtypes-arch.h b/sysdeps/x86_64/htl/bits

Re: [PATCH 6/6] enable syscalls on x86_64

On Sun, Feb 12, 2023 at 8:04 PM Luca Dariz wrote: > -// TODO: test it before dropping ud2 > - ud2 Hi; could you please tell me how you are testing this? What userland code do you run? How does it make syscalls, does it use lcall $7, $0 like on i386, or what? Sergey

Re: [PATCH v2 1/4] hurd: Simplify init-first.c further

(shared vs static, args already on the stack vs not, exec server present vs not) If so, maybe I could run just them and not the full thing; that would be easier on my system. > Sergey Bugaev via Libc-alpha, le mer. 22 févr. 2023 00:19:29 +0300, a ecrit: > > This drops all of the return add

[PATCH v3 1/2] hurd: Simplify init-first.c further

This drops all of the return address rewriting kludges. The only remaining hack is the jump out of a call stack while adjusting the stack pointer. Signed-off-by: Sergey Bugaev --- sysdeps/mach/hurd/dl-sysdep.c | 4 +- sysdeps/mach/hurd/dl-sysdep.h | 4 + sysdeps/mach/hurd/i386

[PATCH v3 2/2] hurd: Generalize init-first.c to support x86_64

Signed-off-by: Sergey Bugaev --- sysdeps/mach/hurd/{i386 => x86}/init-first.c | 6 ++ 1 file changed, 6 insertions(+) rename sysdeps/mach/hurd/{i386 => x86}/init-first.c (97%) diff --git a/sysdeps/mach/hurd/i386/init-first.c b/sysdeps/mach/hurd/x86/init-first.c similarity index 97%

Re: [PATCH 6/6] enable syscalls on x86_64

On Wed, Feb 22, 2023 at 6:31 PM Luca Dariz wrote: > yes this is the entry point through the call gate, it works with any > 32-bit binary that you can compile on 32-bit hurd. For testing you can > use a ramdisk, like the installer, or some simple executable (I have my > own scripts [0] that I woul

intr-msg / hurdsig looks broken, is my analysis correct?

Hello yet again! I'm looking at sysdeps/mach/hurd/i386/intr-msg.h in glibc -- with the intention of eventually porting it to x86_64, but that's out of the question for now, trying to understand it first. The three other relevant source files for it seem to be: 1. hurd/intr-msg.c -- this is the mai

Re: intr-msg / hurdsig looks broken, is my analysis correct?

On Mon, Feb 27, 2023 at 7:39 PM Samuel Thibault wrote: > > Are there any tests for this at all? > > It's very difficult to test since it's all about race conditions, with > the interruption happening exactly at the wrong moment. Right, but can't it be made reliable with some creative use of ptrac

Re: [PATCH 5/5] x86_64: add 64-bit syscall entry point

On Mon, Feb 27, 2023 at 11:46 PM Luca Dariz wrote: > > While theoretically we could still use the same call gate as for > 32-bit userspace, it doesn't seem very common, and gcc seems to not > encode properly the instruction. Instead we use syscall/sysret as > other kernels (e.g. XNU,Linux). This v

Re: [PATCH 5/5] x86_64: add 64-bit syscall entry point

> But then glibc does not actually use mach/syscall_sw.h, it has its own > syscall impl Uh, actually looks like it does both. Fun! :) Sergey

Re: [PATCH 5/5] x86_64: add 64-bit syscall entry point

On Tue, Feb 28, 2023 at 10:18 AM Samuel Thibault wrote: > > Sergey Bugaev, le mar. 28 févr. 2023 09:39:40 +0300, a ecrit: > > > + : \ > > > + : "c" (regaddr), "a" (low), &q

Re: [PATCH 5/5] x86_64: add 64-bit syscall entry point

On Tue, Feb 28, 2023 at 4:26 PM Luca Dariz wrote: > >> +/* check if we need to place some arguments on the stack */ > >> +_syscall64_args_stack: > >> +mov EXT(mach_trap_table)(%rax),%r10 /* get number of arguments */ > >> +subq$6,%r10 /* the first 6 args are alr

Re: [PATCH 5/5] x86_64: add 64-bit syscall entry point

Samuel Thibault wrote: > Sergey Bugaev, le mar. 28 févr. 2023 17:14:05 +0300, a ecrit: > > Do I understand it right that for the most interesting syscall (which > > takes 7 args!), I *am* supposed to pass the 7th arg on the stack (in > > mem[rsp + 8]) > > That's the x86_

Re: intr-msg / hurdsig looks broken, is my analysis correct?

So I implemented this, and it seems to work — as in, signals arrive and handlers run. It's extremely unlikely that I managed to hit the interesting code path where eip is inside that piece of code, so who knows whether that works or not — especially given this has been apparently broken in glibc fo

[PATCH 2/2] hurd: Fix some broken indentation

Also, fix a couple of typos. No functional change. Signed-off-by: Sergey Bugaev --- hurd/hurdsig.c | 93 +- 1 file changed, 47 insertions(+), 46 deletions(-) diff --git a/hurd/hurdsig.c b/hurd/hurdsig.c index 3e759ae5..1c85b29f 100644 --- a/hurd

[PATCH 1/2] hurd: Fully remove the ecx kludge

respect to what the value of esp is and what the code expects it to be. So it is fine to remove this, since the value of esp is no longer inconsistent. Fix the issue by removing all traces of "the ecx kludge", which also simplifies things nicely and paves the way for a future x86_6

Re: [PATCH 5/5] x86_64: add 64-bit syscall entry point

On Wed, Mar 1, 2023 at 12:04 AM Samuel Thibault wrote: > That looks like pure luck :) That looks like mach_msg was overdesigned, if you ask me :) But at least we don't have mach_msg_overwrite, which has... 9 args! Sergey

Re: intr-msg / hurdsig looks broken, is my analysis correct?

On Wed, Mar 1, 2023 at 12:09 AM Samuel Thibault wrote: > > Sergey Bugaev, le mar. 28 févr. 2023 18:53:05 +0300, a ecrit: > > Really, why would it matter whether eip is after > > _hurd_intr_rpc_msg_about_to or not? What if it's 1 instruction before > > that? We ski

[PATCH 2/2] hurd: Fix some broken indentation

Also, fix a couple of typos. No functional change. Signed-off-by: Sergey Bugaev --- hurd/hurdsig.c | 101 + 1 file changed, 51 insertions(+), 50 deletions(-) diff --git a/hurd/hurdsig.c b/hurd/hurdsig.c index 5ff0a91f..85bd46b5 100644 --- a/hurd

[PATCH 1/2] hurd: Remove the ecx kludge

just make it jump to after the trap since it's not done adjusting the stack yet, set the SYSRETURN register to MACH_SEND_INTERRUPTED (as we do anyway), and rely on the thread itself for detecting this case and skipping the RPC. This simplifies things somewhat and paves the way for a future

Re: [PATCH 5/5 v2 gnumach] x86_64: add 64-bit syscall entry point

On Thu, Mar 2, 2023 at 4:14 PM Samuel Thibault wrote: > Ok, then perhaps > > "memory" /* wrmsr usage needs serialization from the compiler too */ How about /* wrmsr may cause a read from memory, so make the compiler flush any changes */ Sergey

Terrible mDNS responder

Hi, this is a shameless self-promotion :) I have posted about the Terrible mDNS responder on Mastodon before, but not on this list, and I have been making minor changes to it recently, so I thought I might as well announce it here, perhaps it could be useful to someone. Debian GNU/Hurd comes with

Re: Terrible mDNS responder

> Hmmm... How do you run the Hurd? Do you run linux on bare metal and > then Hurd on qemu? Yes. I run Hurd on a qemu/libvirt VM that itself runs on GNU/Linux. > When you are typing "herd.local" what does that > mean? > > I suppose that means on your linux machine you are typing "ssh > hurd.local

Re: [PATCH 5/5] x86_64: add 64-bit syscall entry point

On Wed, Mar 1, 2023 at 9:44 AM Luca Dariz wrote: > Il 28/02/23 15:14, Sergey Bugaev ha scritto: > > - nothing else is clobbered, in particular not rflags (or is the > > "reserved" half of rflags clobbered?) and not the registers that > > contain args > > if we

Re: [PATCH 5/5] x86_64: add 64-bit syscall entry point

Speaking of wrapping the syscall and INTR_MSG_TRAP, I might need a little help — is there a proper way to tell GCC that my inline assembly needs a specific register as input _and_ clobbers it? In Rust, this would be, for instance, asm!("whatever", inout("rdi") msg => _) but GCC doesn't like asm

Re: [PATCH gnumach] Align mach_msg_type_t and mach_msg_type_long_t with the same alignment as uintptr_t.

Hi, this seems to break the x86_64 --disable-user32 gnumach build for me: vm/memory_object_user.user.c: In function ‘memory_object_init’: vm/memory_object_user.user.c:128:9: error: static assertion failed: "Request expected to be 80 bytes" 128 | _Static_assert(sizeof(Request) == 80, "Re

Re: [PATCH gnumach] Align mach_msg_type_t and mach_msg_type_long_t with the same alignment as uintptr_t.

On Thu, Mar 9, 2023 at 10:39 AM Flávio Cruz wrote: > I suspect you have to rebuild MiG because it needs to get the new definitions > for mach_msg_type_t and mach_msg_type_long_t. Let me know if you still run > into problems. Ah, so I should do 'make install-data' to put new gnumach headers in pla

Re: [PATCH gnumach] Align mach_msg_type_t and mach_msg_type_long_t with the same alignment as uintptr_t.

On Thu, Mar 9, 2023 at 12:07 PM Sergey Bugaev wrote: > On Thu, Mar 9, 2023 at 10:39 AM Flávio Cruz wrote: > > I suspect you have to rebuild MiG because it needs to get the new > > definitions > > for mach_msg_type_t and mach_msg_type_long_t. Let me know if you still

x86_64-gnu port -- help needed

Hello! So continuing with the x86_64-gnu port, I wrote and tweaked some things and got it to compile further, and now I'm facing linking issues. I've been scratching my head (figuratively...) about this one for > 24 hours now, so it's only appropriate that I ask for some help. First, the error me

Re: x86_64-gnu port -- help needed

On Thu, Mar 9, 2023 at 8:26 PM Andreas Schwab wrote: > Similarily, something is pulling in strtoul.os because it references a > symbol from there not defined by ../sysdeps/mach/hurd/dl-sysdep.c. > > elf/librtld.mapT should tell you where the references come from. Thank you!!! Apparently I'm misu

Re: [PATCH gnumach] Use c_string to define host_get_kernel_version and host_get_kernel_boot_info.

On Wed, Mar 15, 2023 at 9:19 AM Flávio Cruz wrote: > Still, at the > end of the day we should only have two ways of defining strings, either > through > c_string or by using variable arrays as defined by data_t. Hi, I have not looked at your string patches in detail, but please tell me we're fi

[RFC PATCH gnumach 01/34] Add i386_fsgs_base_state

--- i386/include/mach/i386/thread_status.h | 8 1 file changed, 8 insertions(+) diff --git a/i386/include/mach/i386/thread_status.h b/i386/include/mach/i386/thread_status.h index 3de22ff3..32e40686 100644 --- a/i386/include/mach/i386/thread_status.h +++ b/i386/include/mach/i386/thread_s

[RFC PATCH glibc 09/34] hurd: Fix _hurd_setup_sighandler () signature

Signed-off-by: Sergey Bugaev --- hurd/trampoline.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/hurd/trampoline.c b/hurd/trampoline.c index a0639a20..5bd8dec9 100644 --- a/hurd/trampoline.c +++ b/hurd/trampoline.c @@ -26,11 +26,11 @@ that structure

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

As far as I can see, this file was imported in the very beginning of GNU Mach history, and unused since then. Nobody implements or uses this interface. GNU Mach uses a different way to pass the privileged ports to the bootstrap tasks: instead of the task(s) actively asking for the ports in an RPC,

[RFC PATCH glibc 05/34] hurd: Remove __hurd_threadvar_stack_{offset, mask}

-off-by: Sergey Bugaev --- hurd/Versions | 5 - hurd/hurd/threadvar.h | 15 --- sysdeps/mach/hurd/Versions | 3 --- sysdeps/mach/hurd/_Fork.c | 20 ++-- sysdeps/mach/hurd/i386/libc.abilist | 2 -- sysdeps/mach

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

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 requires matching changes in glibc and the Hurd. --- NOTE: Most of this was a pretty mechanical change, but I'm not very sure I got the exc

[RFC PATCH glibc 11/34] mach, hurd: Drop __libc_lock_self0

h GOT, and exporting it from libc.so in the first place. Signed-off-by: Sergey Bugaev --- sysdeps/mach/hurd/Versions | 4 ++-- sysdeps/mach/hurd/cthreads.c | 4 sysdeps/mach/libc-lock.h | 3 +-- 3 files changed, 3 insertions(+), 8 deletions(-) diff --git a/sysdeps/mach/hurd/Versi

[RFC PATCH glibc 29/34] hurd: Add vm_param.h for x86_64

Signed-off-by: Sergey Bugaev --- sysdeps/mach/hurd/x86_64/vm_param.h | 24 1 file changed, 24 insertions(+) create mode 100644 sysdeps/mach/hurd/x86_64/vm_param.h diff --git a/sysdeps/mach/hurd/x86_64/vm_param.h b/sysdeps/mach/hurd/x86_64/vm_param.h new file mode

[RFC PATCH glibc 28/34] hurd: Implement _hurd_longjmp_thread_state for x86_64

Signed-off-by: Sergey Bugaev --- sysdeps/mach/hurd/x86_64/longjmp-ts.c | 41 +++ 1 file changed, 41 insertions(+) create mode 100644 sysdeps/mach/hurd/x86_64/longjmp-ts.c diff --git a/sysdeps/mach/hurd/x86_64/longjmp-ts.c b/sysdeps/mach/hurd/x86_64/longjmp-ts.c new

[RFC PATCH glibc 31/34] hurd: Microoptimize _hurd_self_sigstate ()

When THREAD_GETMEM is defined with inline assembly, the compiler may not optimize away the two reads of _hurd_sigstate. Help it out a little bit by only reading it once. This also makes for a slightly cleaner code. Signed-off-by: Sergey Bugaev --- hurd/hurd/signal.h | 8 +--- 1 file changed

[RFC PATCH 00/34] The rest of the x86_64-gnu port

Hello! (Naturally, the subject line is a reference to the "How to draw an owl" meme.) It's been more than a month since I've tried to run ./configure --host=x86_64-gnu and see what would come out of it, and here we are now: with these patches, glibc fully builds, and even somewhat "works"! On te

[RFC PATCH glibc 32/34] hurd: Implement sigreturn for x86_64

Signed-off-by: Sergey Bugaev --- sysdeps/mach/hurd/x86_64/sigreturn.c | 155 +++ 1 file changed, 155 insertions(+) create mode 100644 sysdeps/mach/hurd/x86_64/sigreturn.c diff --git a/sysdeps/mach/hurd/x86_64/sigreturn.c b/sysdeps/mach/hurd/x86_64/sigreturn.c new file

[RFC PATCH glibc 25/34] hurd: Improve reply port handling when exiting signal handlers

task has any other references to the same port. Signed-off-by: Sergey Bugaev --- NOTE: I don't really understand why sigunwind wants to destroy both its current reply port and user's reply port. Prior to commit fb304035c41c7ee2afede51e5e8568974549ba5e, it was *restoring* the user's

[RFC PATCH glibc 07/34] hurd: Fix file name in #error

Signed-off-by: Sergey Bugaev --- hurd/longjmp-ts.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hurd/longjmp-ts.c b/hurd/longjmp-ts.c index bc4add32..0032d747 100644 --- a/hurd/longjmp-ts.c +++ b/hurd/longjmp-ts.c @@ -27,5 +27,5 @@ _hurd_longjmp_thread_state (void *state

[RFC PATCH glibc 26/34] hurd: Remove __hurd_local_reply_port

THREAD_SETMEM directly, avoiding possible miscompilations. Signed-off-by: Sergey Bugaev --- hurd/hurd/threadvar.h | 7 -- sysdeps/mach/hurd/mig-reply.c | 43 +++ 2 files changed, 33 insertions(+), 17 deletions(-) diff --git a/hurd/hurd/threadvar.

[RFC PATCH glibc 18/34] hurd: Port trampoline.c to x86_64

Signed-off-by: Sergey Bugaev --- Same as for intr-msg.h, can't know whether this works until we try it. sysdeps/mach/hurd/{i386 => x86}/trampoline.c | 139 ++- 1 file changed, 132 insertions(+), 7 deletions(-) rename sysdeps/mach/hurd/{i386 => x86}/trampoline.c

[RFC PATCH glibc 15/34] hurd: Use uintptr_t for register values in trampoline.c

This is more correct, if only because these fields are defined as having the type unsigned int in the Mach headers, so casting them to a signed int and then back is suboptimal. Also, remove an extra reassignment of uesp -- this is another remnant of the ecx kludge. Signed-off-by: Sergey Bugaev

[RFC PATCH glibc 08/34] hurd: Disable O_TRUNC and FS_RETRY_MAGICAL in rtld

real Mach port names as fds. Thus, once libc.so is loaded, rtld will gain access to the full __hurd_file_name_lookup_retry () version, complete with FS_RETRY_MAGICAL support, which is important in case the program decides to dlopen ("/proc/self/fd/...") or some such. Signed-off-by:

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

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_exec exist on the Hurd as of now. Compile this code out to fix build failures. Signed-off-by: Sergey Bugaev --- sysdeps/x86/cpu

[RFC PATCH glibc 20/34] htl: Add tcb-offsets.sym for x86_64

The source code is the same as sysdeps/i386/htl/tcb-offsets.sym, but of course the produced tcb-offsets.h will be different. Signed-off-by: Sergey Bugaev --- sysdeps/x86_64/htl/Makefile| 20 sysdeps/x86_64/htl/tcb-offsets.sym | 8 2 files changed, 28

[RFC PATCH glibc 19/34] hurd: Move a couple of singal-related files to x86

These do not need any changes to be used on x86_64. Signed-off-by: Sergey Bugaev --- sysdeps/mach/hurd/{i386 => x86}/exc2signal.c | 0 sysdeps/mach/hurd/{i386 => x86}/signal-defines.sym | 0 2 files changed, 0 insertions(+), 0 deletions(-) rename sysdeps/mach/hurd/{i386

[RFC PATCH glibc 30/34] hurd: Implement longjmp for x86_64

Signed-off-by: Sergey Bugaev --- sysdeps/mach/hurd/x86_64/longjmp_chk.S | 134 + sysdeps/mach/hurd/x86_64/__longjmp.S | 102 2 files changed, 236 insertions(+) create mode 100644 sysdeps/mach/hurd/x86_64/longjmp_chk.S create mode 100644

[RFC PATCH glibc 24/34] hurd: Only check for TLS initialization inside rtld or in static builds

__libc_tls_initialized variable between ld.so and libc.so that we would have to do otherwise -- we know for sure that no sharing is required, simply because __libc_tls_initialized would always be set to true inside libc.so. Signed-off-by: Sergey Bugaev --- sysdeps/mach/hurd/Makefile

[RFC PATCH glibc 27/34] hurd: Don't leak __hurd_reply_port0

nd an extra syscall to create a new reply port for the TCB. Signed-off-by: Sergey Bugaev --- sysdeps/mach/hurd/i386/tls.h | 5 + sysdeps/mach/hurd/x86_64/tls.h | 9 - 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/sysdeps/mach/hurd/i386/tls.h b/sysdeps/mach/hurd/i386/

[RFC PATCH glibc 10/34] stdio-common: Fix building when !IS_IN (libc)

In this case, _itoa_word () is already defined inline in the header (see sysdeps/generic/_itoa.h), and the second definition causes an error. Signed-off-by: Sergey Bugaev --- stdio-common/_itoa.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/stdio-common/_itoa.c b/stdio-common/_itoa.c

[RFC PATCH glibc 14/34] hurd: Move rtld-strncpy-c.c out of mach/hurd/

There's nothing Mach- or Hurd-specific about it; any port that ends up with rtld pulling in strncpy will need this. Signed-off-by: Sergey Bugaev --- sysdeps/{mach/hurd => }/i386/i686/multiarch/rtld-strncpy-c.c | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename sysdeps/{m

[RFC PATCH glibc 33/34] hurd: Create abilist files for lib{mach, hurd}user

nd sysdeps/mach/hurd/ down to sysdeps/mach/hurd/i386/, while keeping the base abilist versions empty. Signed-off-by: Sergey Bugaev --- sysdeps/mach/hurd/i386/libhurduser.abilist | 754 + sysdeps/mach/hurd/i386/libmachuser.abilist | 336 + 2 files changed, 1090

[RFC PATCH glibc 04/34] hurd: Make exception subcode a long

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 matches the corresponding change in GNU Mach. --- hurd/catch-exc.c | 2 +- hurd/hurd/signal.h | 5 +++-- hurd/hurdfault.c | 2 +- 3 file

[RFC PATCH glibc 22/34] htl: Implement thread_set_pcsptp for x86_64

Signed-off-by: Sergey Bugaev --- sysdeps/mach/hurd/x86_64/htl/pt-machdep.c | 73 +++ 1 file changed, 73 insertions(+) create mode 100644 sysdeps/mach/hurd/x86_64/htl/pt-machdep.c diff --git a/sysdeps/mach/hurd/x86_64/htl/pt-machdep.c b/sysdeps/mach/hurd/x86_64/htl/pt

[RFC PATCH glibc 12/34] hurd: More 64-bit integer casting fixes

Signed-off-by: Sergey Bugaev --- sysdeps/mach/hurd/ioctl.c | 4 ++-- sysdeps/mach/hurd/x86/init-first.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/sysdeps/mach/hurd/ioctl.c b/sysdeps/mach/hurd/ioctl.c index 0f5de5d3..ab913a59 100644 --- a/sysdeps/mach/hurd

[RFC PATCH glibc 06/34] hurd: Swap around two function calls

...to keep `sigexc' port initialization in one place, and match what the comments say. No functional change. Signed-off-by: Sergey Bugaev --- hurd/hurdfault.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/hurd/hurdfault.c b/hurd/hurdfault.c index a81

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

Nothing in there needs tls.h Signed-off-by: Sergey Bugaev --- sysdeps/generic/ldsodefs.h | 1 - 1 file changed, 1 deletion(-) diff --git a/sysdeps/generic/ldsodefs.h b/sysdeps/generic/ldsodefs.h index c99dad77..5f21bc63 100644 --- a/sysdeps/generic/ldsodefs.h +++ b/sysdeps/generic/ldsodefs.h

[RFC PATCH glibc 17/34] hurd: Implement x86_64/intr-msg.h

Signed-off-by: Sergey Bugaev --- This is a prelimenary version of intr-msg.h. I can't know whether or not it works until we can test it. The code relies on syscall preserving values of the registers used to pass syscall arguments. The code in SYSCALL_EXAMINE that just compares two bytes t

[RFC PATCH glibc 16/34] hurd: Add sys/ucontext.h and sigcontext.h for x86_64

This is based on the Linux port's version, but laid out to match Mach's struct i386_thread_state, much like the i386 version does. Signed-off-by: Sergey Bugaev --- I'm not very sure about the FP stuff, nor about any of this, really. Please do review. sysdeps/mach/hurd/x86_64/bi

[RFC PATCH glibc 21/34] x86_64: Add rtld-stpncpy & rtld-strncpy

Just like the other existing rtld-str* files, this provides rtld with usable versions of stpncpy and strncpy. Signed-off-by: Sergey Bugaev --- sysdeps/x86_64/multiarch/rtld-stpncpy.S | 18 ++ sysdeps/x86_64/multiarch/rtld-strncpy.S | 18 ++ 2 files changed, 36

Re: [RFC PATCH glibc 33/34] hurd: Create abilist files for lib{mach, hurd}user

On Sun, Mar 19, 2023 at 6:19 PM Samuel Thibault wrote: > > Hello, > > Thanks for this work! :D Yay! Can you believe just how glad I am to finally have completed it :D > I don't have the time now to review the whole series, just a comment > here: we don't really want to introduce abilist for lib{

Re: [RFC PATCH 00/34] The rest of the x86_64-gnu port

(un-cc-ing libc-alpha) > One reason for troubles in testing with gnumach is that rpc don't work > very well yet... Simple syscalls should work if you take my patch with > syscall64 v3, and also some simple rpcs, but in general I still see some > issues with the 64-bit message format and the mig-ge

[PATCH v2] hurd: Add expected abilist files for x86_64

nable? I've dropped lib{mach,hurd}user, and it seems libanl, libnsl, libutil are all gone. Sergey -- >8 -- These were created by creating stub files, running 'make update-abi', and reviewing the results. Signed-off-by: Sergey Bugaev --- sysdeps/mach/hurd/x86_64/shlib-versi

Re: [RFC PATCH 00/34] The rest of the x86_64-gnu port

On Sun, Mar 19, 2023 at 11:13 PM Luca wrote: > > How do you even attach gdb to qemu properly without racing against > > Mach starting up? qemu -S doesn't work (unlike on i386), since if you > > attach GDB immediately at startup, it freaks out about some message > > size mismatch, apparently relate

Re: [RFC PATCH 00/34] The rest of the x86_64-gnu port

On Tue, Mar 21, 2023 at 11:36 AM Luca wrote: > > Il 20/03/23 20:10, Sergey Bugaev ha scritto: > > I've gone through the process again (without GDB, even, for now). > > Attaching two screenshots: the first one shows what I input to GRUB > > (seemingly all correct?),

Re: [RFC PATCH 00/34] The rest of the x86_64-gnu port

On Tue, Mar 21, 2023 at 1:28 PM Sergey Bugaev wrote: > > On Tue, Mar 21, 2023 at 12:48 PM Luca wrote: > > Great! if you still have issues with the long mode, you could try to > > hack gnumach to wait at some point (e.g. user_bootstrap() or > > setup_main()), attach wi

Re: [RFC PATCH 00/34] The rest of the x86_64-gnu port

On Tue, Mar 21, 2023 at 2:04 PM Sergey Bugaev wrote: > It seems to parse the bootscript correctly. It starts the initial > thread, which loads the ELF and then hangs right here (on printf???): > > > > Does that ring any bells? Maybe this will shed some light: (gdb) s charput

Re: [RFC PATCH 00/34] The rest of the x86_64-gnu port

On Tue, Mar 21, 2023 at 3:20 PM Luca wrote: > did you add $(task-resume) in the boot script? $(prompt-task-resume), yes. But (see my later mail) Mach hits a page fault trying to printf "task loaded:", it never gets to resuming the task. This must be due to some difference in how we're running QE

Re: [RFC PATCH 00/34] The rest of the x86_64-gnu port

On Tue, Mar 21, 2023 at 3:52 PM Luca wrote: > > Il 21/03/23 13:37, Sergey Bugaev ha scritto: > > On Tue, Mar 21, 2023 at 3:20 PM Luca wrote: > >> did you add $(task-resume) in the boot script? > > > > $(prompt-task-resume), yes. > > > > But (see my

Re: [RFC PATCH 00/34] The rest of the x86_64-gnu port

On Tue, Mar 21, 2023 at 5:19 PM Luca wrote: > > Every thread needs to have its own values of fs_base / gs_base, and > > you need to store/restore them on context switch by accessing the > > appropriate MSR. There's also the swapgs instruction that I'm told is > > useful if you also use gs for kern

Re: [RFC PATCH 00/34] The rest of the x86_64-gnu port

On Tue, Mar 21, 2023 at 5:19 PM Luca wrote: > > Every thread needs to have its own values of fs_base / gs_base, and > > you need to store/restore them on context switch by accessing the > > appropriate MSR. There's also the swapgs instruction that I'm told is > > useful if you also use gs for kern

Re: [RFC PATCH 00/34] The rest of the x86_64-gnu port

On Tue, Mar 21, 2023 at 6:33 PM Almudena Garcia wrote: > > But how does a core know its CPU number? > > Calling cpu_number() function, or getting its APIC ID from its Local APIC Ah. That's too hardware-y for me to understand; but I see that cpu_number () in i386/i386/cpu_number.c also uses apic,

Re: Help with libcap build

On Sat, Mar 25, 2023 at 10:56 PM Sahil Ahmed wrote: > Hi, > I m trying to build libcap on debian/hurd and the error said no > found. Hello, I think the issue lies quite a bit deeper than not being present on a Debian/Hurd system ;) Namely, to my knowledge, Hurd doesn't implement POSIX capabil

GDB breakpoints are broken in new threads -- here's why

Hello -- and pardon the clickbait-y subject line (a large part of this was written yesterday, on April 1st :) While debugging my multi-threaded translator [0], I ran into an annoying issue: when I set a breakpoint on a server-side MIG routine (S_dir_readdir in my specific case) and send the matchi

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

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

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

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

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

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 glibc 13/34] x86-64: Disable prefer_map_32bit_exec tunable on non-Linux

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, neithe

[PATCH v2] hurd: Implement sigreturn for x86_64

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

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

g* to volatile memory (volatile void *sigsp), but evidently that's not needed either. Signed-off-by: Sergey Bugaev --- hurd/trampoline.c | 2 +- sysdeps/mach/hurd/i386/trampoline.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/hurd/trampolin

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

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.)

<    1   2   3   4   5   6   7   8   9   >