Sergey Bugaev, le mer. 03 janv. 2024 21:56:54 +0300, a ecrit:
> perhaps I need to try two of them in parallel and some I/O-heavy
> workload in the background, as you're saying.
Yes, that's needed to raise the probability of the bug.
> Could it be that the two strings are actually different (somet
Sergey Bugaev, le jeu. 04 janv. 2024 00:24:30 +0300, a ecrit:
> On Thu, Jan 4, 2024 at 12:08 AM Sergey Bugaev wrote:
> > This is testing installed headers, isn't it? — then
> > how come sysdeps/hurd/include/hurd.h is what gets found for ?
> > I'm rather sure the installed is a different file. So
On Thu, Jan 4, 2024 at 12:08 AM Sergey Bugaev wrote:
> This is testing installed headers, isn't it? — then
> how come sysdeps/hurd/include/hurd.h is what gets found for ?
> I'm rather sure the installed is a different file. So it
> would look like the test setup is broken, and this patch just exp
On Wed, Jan 3, 2024 at 11:43 PM Samuel Thibault wrote:
> Sergey Bugaev, le mer. 03 janv. 2024 20:14:34 +0300, a ecrit:
> > diff --git a/sysdeps/hurd/include/hurd.h b/sysdeps/hurd/include/hurd.h
> > index 568092d6..189fd44e 100644
> > --- a/sysdeps/hurd/include/hurd.h
> > +++ b/sysdeps/hurd/include
Applied, thanks!
Sergey Bugaev, le mer. 03 janv. 2024 20:14:39 +0300, a ecrit:
> We're obtaining arguments from the stack differently, see init-first.c.
>
> Signed-off-by: Sergey Bugaev
> ---
> sysdeps/mach/sysdep.h | 7 ---
> sysdeps/mach/x86/sysdep.h | 14 --
> 2 files ch
Applied, thanks!
Sergey Bugaev, le mer. 03 janv. 2024 20:14:37 +0300, a ecrit:
> Signed-off-by: Sergey Bugaev
> ---
>
> We should try to include vm_param.h less; this statically asserts that
> these files are not possibly using the PAGE_SIZE definition.
>
> dl-sysdep.c used VM_MAX_ADDRESS for t
Applied, thanks!
Sergey Bugaev, le mer. 03 janv. 2024 20:14:35 +0300, a ecrit:
> These symbols are internal and never exported; make sure the compiler
> realizes that when compiling hurdsig.c and does not try to emit GOT
> reads.
>
> Signed-off-by: Sergey Bugaev
> ---
> hurd/hurdsig.c | 6 +++--
Applied the rest, thanks!
Sergey Bugaev, le mer. 03 janv. 2024 20:14:34 +0300, a ecrit:
> Signed-off-by: Sergey Bugaev
> ---
> hurd/hurdsig.c | 2 +-
> mach/lowlevellock.h| 1 +
> sysdeps/hurd/include/hurd.h| 1 +
> sysdeps/hurd/include/hurd/signal.h |
Sergey Bugaev, le mer. 03 janv. 2024 20:14:34 +0300, a ecrit:
> diff --git a/sysdeps/hurd/include/hurd.h b/sysdeps/hurd/include/hurd.h
> index 568092d6..189fd44e 100644
> --- a/sysdeps/hurd/include/hurd.h
> +++ b/sysdeps/hurd/include/hurd.h
> @@ -1,4 +1,5 @@
> #ifndef _HURD_H
> +#include
>
Luca, le mer. 03 janv. 2024 20:07:00 +0100, a ecrit:
> Il 03/01/24 09:17, Sergey Bugaev ha scritto:
> > How are you running it? Should I still be using a ramdisk image and
> > not rumpdisk?
>
> Recently I've been installing hurd-amd64 on another disk of my hurd-i386 vm
> and booting from that. Bas
Hi Sergey,
Il 03/01/24 09:17, Sergey Bugaev ha scritto:
How are you running it? Should I still be using a ramdisk image and
not rumpdisk?
Recently I've been installing hurd-amd64 on another disk of my hurd-i386
vm and booting from that. Basically I prepare the disk with debootstrap
--foreign
On Wed, Jan 3, 2024 at 11:27 AM Samuel Thibault wrote:
> Sergey Bugaev, le mer. 03 janv. 2024 11:17:53 +0300, a ecrit:
> > I guess this is where I ask (consistent with the subject line) about
> > how I would run the x86_64 system (to reproduce & debug this).
>
> You probably want to start with the
On Wed, Jan 3, 2024 at 8:30 PM Joseph Myers wrote:
> I think the same principle applies for ports to new (architecture, Hurd)
> pairs as for new (architecture, Linux) pairs: the relevant code needs to
> be in upstream mainline of all components on which glibc build-depends
> before the port can go
On Wed, 3 Jan 2024, Sergey Bugaev wrote:
> To build this, you need an aarch64-gnu toolchain (binutils, GCC, MIG),
> and GNU Mach headers for AArch64. I have posted the patches for
> binutils, GCC, and GNU Mach to the bug-hurd mailing list; no patches
> are required to build aarch64-gnu-mig.
> The
We're obtaining arguments from the stack differently, see init-first.c.
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/sysdep.h | 7 ---
sysdeps/mach/x86/sysdep.h | 14 --
2 files changed, 21 deletions(-)
diff --git a/sysdeps/mach/sysdep.h b/sysdeps/mach/sysdep.h
index 8eeac
Signed-off-by: Sergey Bugaev
---
We should try to include vm_param.h less; this statically asserts that
these files are not possibly using the PAGE_SIZE definition.
dl-sysdep.c used VM_MAX_ADDRESS for the "loser kludge for vm_map kernel
bug"; that bug has been fixed and the kludge removed. setup
Instead of relying on the stack frame layout to figure out where the stack
pointer was prior to the _hurd_stack_setup () call, just pass the pointer
as an argument explicitly. This is less brittle and much more portable.
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/i386/static-start.S |
We fetch __vm_page_size as the very first RPC that we do, inside
__mach_init (). Propagate that to _dl_pagesize ASAP after that,
before any other initialization.
In dynamic builds, this is already done immediately after
__mach_init (), inside _dl_sysdep_start ().
Signed-off-by: Sergey Bugaev
---
While we could support it on any architecture, the tunable is currently
only defined on x86_64.
Signed-off-by: Sergey Bugaev
---
Alternatively, we could declare the tunable for all Hurd ports (e.g. in
sysdeps/mach/hurd/dl-tunables.list), but I'm concerned about whether it
would interact well wit
The following commits will add TLS, HTL, and the signal bits.
Signed-off-by: Sergey Bugaev
---
We're using GLIBC_2.39 as the baseline shlib version.
static-start.S reproduces the same GOT pre-filling trick as on x86_64; I
have verified that this does not prevent real implementations from being
Signed-off-by: Sergey Bugaev
---
This is somewhat complete, but untested. Notably absent is a
sigreturn () implementation, which would depend on whether we manage to
make thread_set_state () able to operate on the calling thread.
I didn't bother too much with exception2signal () because the deta
This is based on the generic AArch64 version, but it additionally
respects and updates the Hurd sigstate.
Signed-off-by: Sergey Bugaev
---
This is also entirely untested. Please review carefully.
sysdeps/aarch64/htl/tcb-offsets.sym | 5 +
sysdeps/mach/hurd/aarch64/Makefile
This is the case on both x86 architectures, but not on AArch64.
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/init-first.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/sysdeps/mach/hurd/init-first.c b/sysdeps/mach/hurd/init-first.c
index 85261916..26c
This is a new si_code value for the SIGFPE signal that has been added
to FreeBSD, and is also going to be used on the Hurd.
Signed-off-by: Sergey Bugaev
---
bits/siginfo-consts.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/bits/siginfo-consts.h b/bits/siginfo-consts.h
This doesn't add any of the Hurd- or HTL-specific bits yet.
Signed-off-by: Sergey Bugaev
---
I don't think RPC_aarch64_get_hwcaps.c actually needs no-stack-protector
since the stack protector is not (currently?) stored in TLS on AArch64,
but let's have it there for consistency.
cpu-features.c i
These describe generic AArch64 CPU features, and are not tied to a
kernel-specific way of determining them. We can share them between
the Linux and Hurd AArch64 ports.
Signed-off-by: Sergey Bugaev
---
sysdeps/{unix/sysv/linux => }/aarch64/cpu-features.h | 0
sysdeps/{unix/sysv/linux => }/aarch64
This will make it usable in other ports.
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/{x86 => }/init-first.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename sysdeps/mach/hurd/{x86 => }/init-first.c (98%)
diff --git a/sysdeps/mach/hurd/x86/init-first.c b/sysdeps/mach/hurd
This is using TLS_DTV_AT_TP, aka "Variant I" layout. tpidr_el0, which is
both readable and writable from userspace, is used as the thread pointer.
We store our Hurd-specific data (sigstate and reply port) *before* the
TCB head, in a tcbprehead_t structure. This tcbprehead_t structure is
also what
Signed-off-by: Sergey Bugaev
---
Also untested.
htl/pt-create.c | 2 ++
sysdeps/htl/dl-thread_gscope_wait.c | 16 ++--
sysdeps/mach/hurd/htl/pt-sysdep.c | 9 +
3 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/htl/pt-create.c b/htl/pt-cr
We already have the RETURN_TO macro for this exact use case, and it's already
used in the non-static code path. Use it here too.
Signed-off-by: Sergey Bugaev
---
This was the last piece of x86 specifics in init-first.c!
(Remember, it started as sysdeps/mach/hurd/i386/init-first.c, with lots of
i
Signed-off-by: Sergey Bugaev
---
This is completely untested.
sysdeps/aarch64/htl/Makefile | 20 +
sysdeps/aarch64/htl/bits/pthreadtypes-arch.h | 36 +
sysdeps/aarch64/htl/machine-sp.h | 29 +++
sysdeps/aarch64/htl/pt-machdep.h | 28 ++
We would like to avoid statically defining any specific page size on
aarch64-gnu, and instead make sure that everything uses the dynamic
page size, available via vm_page_size and GLRO(dl_pagesize).
There are currently a few places in glibc that require EXEC_PAGESIZE
to be defined. Per Roland's sug
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/aarch64/ld.abilist | 18 +
.../mach/hurd/aarch64/libBrokenLocale.abilist |1 +
sysdeps/mach/hurd/aarch64/libanl.abilist |4 +
sysdeps/mach/hurd/aarch64/libc.abilist| 2123 +
.../hurd/aarch64/libc_ma
Hello!
This is my work on the aarch64-gnu port, aka GNU/Hurd on 64-bit ARM.
To build this, you need an aarch64-gnu toolchain (binutils, GCC, MIG),
and GNU Mach headers for AArch64. I have posted the patches for
binutils, GCC, and GNU Mach to the bug-hurd mailing list; no patches
are required to b
This is based on the Linux version, but doesn't define
GLRO(dl_aarch64_cap_flags) and implement _dl_hwcap_string (which seems
unused anyway) based on Linux HWCAP bit values.
Signed-off-by: Sergey Bugaev
---
sysdeps/aarch64/dl-procinfo.c | 59 +++
sysdeps/aarch64/d
If PROT_BTI is not defined, turn _dl_bti_protect () into a no-op.
We intend to support BTI & PROT_BTI on the Hurd eventually, but we're
not there yet.
Signed-off-by: Sergey Bugaev
---
sysdeps/aarch64/dl-bti.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/sysdeps/aarch64/dl-bti
These symbols are internal and never exported; make sure the compiler
realizes that when compiling hurdsig.c and does not try to emit GOT
reads.
Signed-off-by: Sergey Bugaev
---
hurd/hurdsig.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/hurd/hurdsig.c b/hurd/hurdsig
Signed-off-by: Sergey Bugaev
---
hurd/hurdsig.c | 2 +-
mach/lowlevellock.h| 1 +
sysdeps/hurd/include/hurd.h| 1 +
sysdeps/hurd/include/hurd/signal.h | 1 +
sysdeps/mach/hurd/mig-reply.c | 1 +
5 files changed, 5 insertions(+), 1 deletion(-)
diff
Sergey Bugaev writes:
> Since it's not i386-specific; this makes it possible to reuse it for other
> architectures.
>
> Also, add a warning for the case gnu.h is specified before gnu-user.h, which
> would cause gnu-user's version of the spec to override gnu's, and not the
> other
> way around as
Sergey Bugaev, le mer. 03 janv. 2024 11:17:53 +0300, a ecrit:
> I guess this is where I ask (consistent with the subject line) about
> how I would run the x86_64 system (to reproduce & debug this).
You probably want to start with the pre-built images I have linked from
the wiki page.
> I've tried
Hello,
I guess this is where I ask (consistent with the subject line) about
how I would run the x86_64 system (to reproduce & debug this).
I've tried debootstrapping from
https://people.debian.org/~sthibault/tmp/hurd-amd64 as the wiki page
says; but that doesn't proceed beyond the rumpdisk. Rumpd
41 matches
Mail list logo
