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
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
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
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
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
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?),
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
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
(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
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{
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
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
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
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
...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
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
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
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
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
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
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
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/
__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
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
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
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
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
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:
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
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
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.
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
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
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
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
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
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
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
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
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
-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
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,
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
---
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
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
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
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
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
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
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
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
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
> 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
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
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
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
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
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
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
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
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
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
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_
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
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
> 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
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
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
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
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
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%
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
(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
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
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
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
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%
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
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
> 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
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
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
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
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
---
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
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
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
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
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
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/{i386 => x86}/init-first.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
rename sysdeps/mach/hurd/{i386 => x86}/init-first.c (96%)
diff --git a/sysdeps/mach/hurd/i386/init-first.c
b/sysdeps/mach/hurd/x8
And make it a bit more 64-bit ready. This is in preparation to moving this
file into x86/
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/i386/init-first.c | 23 +++
1 file changed, 7 insertions(+), 16 deletions(-)
diff --git a/sysdeps/mach/hurd/i386/init-first.c
b
Hello,
here's some more work on the x86_64-gnu glibc port. Large parts of glibc
(almost all of it?) builds, in particular mach/subdir_lib builds cleanly.
Patch 6 is really unrelated to the rest of the changes, it's just a small thing
that I've noticed while single-stepping through glibc startup,
On Fri, Feb 17, 2023 at 9:02 AM Flávio Cruz wrote:
> Thanks for the instructions. I discovered that mach_msg_type_long_t does not
> align to 8 bytes so it also needs a bit of padding just like mach_msg_type_t.
> See my last patch. I was able to compile most of the glibc and all the stubs
> afte
> With this layout alignment issues seem much simpler to solve, basically
> we can leave the compiler find the best combination for the second part
> of the message, and if the user/kernel archs are the same, the struct
> will have the same layout in the sending and receiving mig stubs.
To be clea
On Thu, Feb 16, 2023 at 10:27 AM Flávio Cruz wrote:
>> On that note: right now, MIG-generated stubs are broken on x86_64. MIG
>> built from master complains about time_value_t (which GCC says is 16
>> bytes-, but MIG expects to be 12 bytes- sized). If I set
>> desired_max_alignof to 8 (which it mu
On Wed, Feb 15, 2023 at 8:51 AM Flávio Cruz wrote:
>> This would be trivial to fix by flipping the line order in aclocal.m4
>> (in each repo that vendors it...), but maybe MIG should actually
>> support this? What does it need the subsystem for anyway, when parsing
>> type defs? Apple's MIG suppor
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 t
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 an
fsets 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
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
501 - 600 of 789 matches
Mail list logo
