Could you please (when you have time, no rush) make another image
without the vm_param.h hack? Ideally, with curl and netcat and a DHCP
client included. (Curl used to be present in the apt packages cache,
but seems to have disappeared from the last image.)
Context: I have some changes here that ad
On Tue, Jun 20, 2023 at 3:59 PM Samuel Thibault wrote:
> Concerning dhcp, isc-dhcp currently FTBFS.
Oh :(
> € file hurd/pfinet
> hurd/pfinet: ELF 64-bit LSB pie executable
I must have been looking in the wrong place then, good.
But non-PIE is definitely the case for hurd-i386, and only for
bin
On Tue, Jun 20, 2023 at 4:00 PM Samuel Thibault wrote:
> (done so)
Works beautifully, thank you :D
root@hurd:/# ldd /bin/bash
libtinfo.so.6 => /lib/x86_64-gnu/libtinfo.so.6 (0x01dc)
libc.so.0.3 => /lib/x86_64-gnu/libc.so.0.3 (0x0100e000)
/lib/ld-x86-64
On Tue, Jun 20, 2023 at 4:55 PM Sergey Bugaev wrote:
> Works beautifully, thank you :D
...no it does not! -- and it's visible from the output I posted. ASLR
works, the huge heap mapping works, but not the other two things.
Investigating now.
Sergey
On Tue, Jun 20, 2023 at 5:07 PM Sergey Bugaev wrote:
> ...no it does not! -- and it's visible from the output I posted. ASLR
> works, the huge heap mapping works, but not the other two things.
> Investigating now.
I must have just used the wrong exec server accidentally. Here:
#
Due to little-endianness of x86, this resulted in a 64-bit pointers that
pointed to the lower 4 GB of the address space being treated as a 32-bit
pointer followed by NULL, which manifested as only the first program arg
(the argv[0]) being visible in ps output. When a pointer pointed outside
of the
The code already ignores proc_mark_important failing with EPERM; do the
same for opening /servers/startup and startup_request_notification. All
of these calls will fail for unprivileged mounts.
Also plug a port leak: we want to deallocate the "init" port whether the
RPC succeeds or not.
---
libdi
The existing code mapped the first PT_LOAD segment using anywhere=1,
letting Mach pick an arbitrary location, and then uses anywhere=0 for
all the remaining segments to place them next to the first one, as
expected by the program.
This, however, runs into many issues, primarily because of conflict
We want to map the whole lower 4 GB of address space inaccessible to
catch accidental pointer truncation. We can only do this when the
executable (as well as the interpreter, if any) is compiled as PIC/PIE,
since otherwise we would violate the ABI requirement. Fortunately most
distributions have al
The user already has full access to our task, and the same kind of
access to the file system image (if any) as our task does, we're not
buying any additional security by disallowing them access.
In practice, this allows creating and arbitrarily modifying ext2
filesystem images owned by an otherwis
inaccessible, as we're planning to do on 64-bit Hurd,
- is just silly.
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/htl/pt-stack-alloc.c | 35 ++-
1 file changed, 6 insertions(+), 29 deletions(-)
diff --git a/sysdeps/mach/htl/pt-stack-alloc.c
b/sysdeps/mach/h
Zero address passed to mmap () typically means the caller doesn't have
any specific preferred address. Not so if MAP_FIXED is passed: in this
case 0 means literal 0. Fix this case to pass anywhere = 0 into vm_map.
Also add some documentation.
Signed-off-by: Sergey Bugaev
---
sysdeps/mach
Only call vm_deallocate when we do have the old buffer, and check for
unexpected errors.
Spotted while debugging a msgids/readdir issue on x86_64-gnu.
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/readdir64.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a
Mach from coalescing the VM map entries.
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/brk.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sysdeps/mach/hurd/brk.c b/sysdeps/mach/hurd/brk.c
index f1349495..3a335194 100644
--- a/sysdeps/mach/hurd/brk.c
+++ b/sysdeps/mach
.
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/bits/mman_ext.h | 7 ++-
sysdeps/mach/hurd/mmap.c | 26 +-
2 files changed, 23 insertions(+), 10 deletions(-)
diff --git a/sysdeps/mach/hurd/bits/mman_ext.h
b/sysdeps/mach/hurd/bits/mman_ext.h
index bbb94743
On Mon, Jun 26, 2023 at 2:11 AM Sergey Bugaev wrote:
> The user already has full access to our task, and the same kind of
> access to the file system image (if any) as our task does, we're not
> buying any additional security by disallowing them access.
This is not necessarily tr
If a mapping of an object is made right next to another mapping of the
same object have the same properties (protection, inheritance, etc.),
Mach will now expand the previous VM map entry to cover the new address
range instead of creating a new entry.
---
vm/vm_map.c| 12 ++--
vm/vm_ob
Hello!
This is the kernel part of the VM work I've been doing lately. I'm no Mach VM
expert (much as I'm not an expert in anything really), but this looks
straightforward enough and seems to work well.
In the Hurd wiki, there's this open issue about "forward merging" VM map
entries [0]. To recap
If a deallocated VM map entry refers to an object that only has a single
reference and doesn't have a pager port, we can eagerly release any
physical pages that were contained in the deallocated range.
This is not a 100% solution: it is still possible to "leak" physical
pages that can never appear
When entering an object into a map, try to extend the next entry
backward, in addition to the previously existing attempt to extend the
previous entry forward.
---
vm/vm_map.c | 39 +++
1 file changed, 35 insertions(+), 4 deletions(-)
diff --git a/vm/vm_map.c b
When
- extending an existing entry,
- changing protection or inheritance of a range of entries,
we can get several entries that could be coalesced. Attempt to do that.
---
vm/vm_map.c | 29 +++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/vm/vm_map.c b/v
Previously, vm_object_coalesce would only succeed with next_object being
VM_OBJECT_NULL (and with the previous patch, with the two object
references pointing to the same object). This patch additionally allows
the inverse: prev_object being VM_OBJECT_NULL and next_object being some
internal VM obje
This function attempts to coalesce a VM map entry with its preceeding
entry. It wraps vm_object_coalesce.
---
vm/vm_map.c | 77 +++--
vm/vm_map.h | 2 ++
2 files changed, 77 insertions(+), 2 deletions(-)
diff --git a/vm/vm_map.c b/vm/vm_map.c
index
struct vm_page is supposed to be a "small structure", but it takes up 96
bytes on x86_64 (to represent a 4k page). By utilizing bitfields and
strategically reordering members to avoid excessive padding, it can be
shrunk to 80 bytes.
- page_lock and unlock_request only need to store a bitmask of
On Mon, Jun 26, 2023 at 2:27 PM Sergey Bugaev wrote:
> + /*
> +* Get rid of the entry without changing any wirings or the pmap,
> + * and without altering map->size.
> +*/
> + prev->vme_end = entry->vme_end;
> + vm_
Hello,
On Mon, Jul 3, 2023 at 3:02 AM Samuel Thibault wrote:
> I applied this, *but* I see:
>
> * Fields in this structure are locked either by the lock on the
> * object that the page belongs to (O) or by the lock on the page
> * queues (P). [Some fields require that both lock
On Mon, Jul 3, 2023 at 2:48 AM Samuel Thibault wrote:
> Sergey Bugaev, le lun. 26 juin 2023 02:11:37 +0300, a ecrit:
> > @@ -1297,17 +1274,6 @@ do_exec (file_t file,
> >finish (&interp, 1);
> > }
> >
> > -
> > - /* Leave room for mmaps et
On Mon, Jul 3, 2023 at 11:40 AM Samuel Thibault wrote:
> Sergey Bugaev, le lun. 03 juil. 2023 11:19:54 +0300, a ecrit:
> > But the brk is at a fixed high address (BRK_START),
>
> On x86_32 it's not that high.
It is pretty high (2 GB), out of the overall 3 GB address space.
vm_object_coalesce() callers used to rely on the fact that it always
merged the next_object into prev_object, potentially destroying
next_object and leaving prev_object the result of the whole operation.
After ee65849bec5da261be90f565bee096abb4117bdd
"vm: Allow coalescing null object with an inter
When
- extending an existing entry,
- changing protection or inheritance of a range of entries,
we can get several entries that could be coalesced. Attempt to do that.
---
vm/vm_map.c | 29 +++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/vm/vm_map.c b/v
This is the remaining patches from "Forward merging entries and other
VM shenanigans" (specifically the vm_map_coalesce_entry part), with
that one issue fixed. And here's a reproducer that fails with v1 and
works now:
Sergey
#define _GNU_SOURCE
#include
#include
#include
#include
#include
This function attempts to coalesce a VM map entry with its preceeding
entry. It wraps vm_object_coalesce.
---
vm/vm_map.c | 78 +++--
vm/vm_map.h | 2 ++
2 files changed, 78 insertions(+), 2 deletions(-)
diff --git a/vm/vm_map.c b/vm/vm_map.c
index
Hi Damien, Vedant --
this is exciting! Some nitpicks (to add to what Amos says) inline.
On Sun, Jul 9, 2023 at 1:05 PM Damien Zammit wrote:
> supported_targets! {
> +("i686-unknown-hurd-gnu", i686_unknown_hurd_gnu),
Arguably the target should be i686-unknown-gnu, and target_os = "gnu".
LLV
On Sun, Jul 9, 2023 at 1:06 PM Damien Zammit wrote:
> Autogenerated mod.rs in 2021 with:
>
> bindgen input.h -- --sysroot=./hurd-headers -I./hurd-headers/include \
> -I./hurd-headers/include/i386-gnu -target i386-gnu > mod.rs
I realize this is autogenerated and not written by you, but:
>
On Mon, Jul 10, 2023 at 10:53 PM Samuel Thibault
wrote:
> llvm calls it i686-unknown-hurd-gnu (that was an intended behavior, even
> when knowing that gnu tools call it i686-unknown-gnu), so we should
> probably stick to that.
>
> I'd tend to keep it "hurd", because "gnu" is confusing for people.
Hi Damien,
On Sun, Jul 16, 2023, 13:39 Damien Zammit wrote:
> This standardises the format of the boot parameters so that
> they all use the same parameter --next-task to specify the next
> task in the boot order.
I mentioned this in some other thread, repeating now: I have this
grand plan for r
Hello,
as said before, I can only nitpick on the implementation details, hope
this is still useful :)
On Sun, Jul 23, 2023 at 6:36 AM Damien Zammit wrote:
> +
> +/*
> + * Request io ports for a specific io region for a device.
> + * The resulting port may be used to call mach rpc i386_io_perm_mo
Hello!
On Tue, Aug 8, 2023 at 8:16 PM Samuel Thibault wrote:
> Hello,
>
> I continued stabbing at the network issue, it was just a size alignment
> problem, so that depending on their sizes, half of the network packets
> would be discarded by mach_msg. Hurd-amd64 packages are getting rebuilt
> to
On Tue, Aug 8, 2023 at 9:16 PM Samuel Thibault wrote:
> I have already upgraded the source being used to 2.38. To keep things
> simple, we will bootstrap from that, not from 2.36 or 2.37.
Ah cool, you're one step ahead of me :)
Sergey
Hello,
On Wed, Aug 9, 2023 at 4:10 AM Samuel Thibault wrote:
> So, is anybody against making this change?
I trust Flávio to understand RPC ABI much better than I do.
That being said, I don't quite understand the point of this change: we
cannot get rid of mach_msg_type_long_t completely on 32-bi
On Wed, Aug 9, 2023 at 12:29 AM Samuel Thibault wrote:
> BTW, to get rumpdisk out of the equation, it would be useful to work on
> moving the kernel map below 0x8000, so we do not get any
> size constraint on it, and thus are able to load initrds of whatever
> size, provided that we ha
On Wed, Aug 9, 2023 at 12:20 PM Samuel Thibault wrote:
> Sergey Bugaev, le mer. 09 août 2023 12:12:29 +0300, a ecrit:
> > It should just reuse whatever memory the bootloader has already loaded
> > the module into, no need to copy it out anywhere.
>
> (my guess is that it&#x
On Wed, Aug 9, 2023 at 8:57 PM Samuel Thibault wrote:
>
> Samuel Thibault, le mar. 08 août 2023 19:15:50 +0200, a ecrit:
> > I continued stabbing at the network issue, it was just a size alignment
> > problem, so that depending on their sizes, half of the network packets
> > would be discarded by
Hello,
On Wed, Aug 30, 2023 at 2:16 AM Samuel Thibault wrote:
> Just to make sure, may your work be affected by this?
>
> https://lists.gnu.org/archive/html/bug-hurd/2017-10/msg00011.html
Yes, I learned about that patch just after having sent mine.
> We had a patch in Debian that was disabling
Hello,
> > > I've started on a fuse port for bcachefs - if you're interested, I'd
> > > happy to spend some time looking at it with you and sketching out what
> > > needs to be done next.
> >
> > Sure that sounds like boat loads of fun! I'm on Eastern standard time.
> > And I am normally free in
On Wed, Oct 25, 2023 at 2:52 PM wrote:
>
> October 25, 2023 3:43 AM, "Samuel Thibault" wrote:
>
> > jbra...@dismail.de, le mer. 25 oct. 2023 03:40:16 +, a ecrit:
> >
> >> Or maybe GCC is partly at fault for the
> >> Hurd's X86_64 building troubles?
> >
> > It's not at all. Nor is libtool.
> >
On Mon, Oct 30, 2023 at 1:27 AM Samuel Thibault wrote:
> Samuel Thibault, le ven. 27 oct. 2023 08:48:19 +0200, a ecrit:
> > while [ "$(echo -n `echo internal/reflectlite.s-gox | sed -e
> > 's/s-gox/gox/' ` )" = internal/reflectlite.gox ] ; do : ; done
>
> For now, I could reproduce with
>
> tim
Hello,
On Wed, Nov 1, 2023 at 9:17 PM Samuel Thibault wrote:
> I tracked it a bit, it seems that libport is not always cleaning
> structures from the proc class. Below is the tracing that we get for
> instance with the while loop above. Alloc is the allocation of pi, free
> is the freeing from th
Hello!
I'm porting the Ladybird browser to build and run on the Hurd. After
having done a bunch of changes and finally getting something built, I
was rewarded with a SIGILL inside innocently looking Qt initialization
code.
Turns out Qt in Debian hurd-i386 was built with -msse2 -mfpmath=sse,
and t
Hello,
On Mon, Dec 18, 2023, 00:56 wrote:
> Hello you lovely people!
>
> Wanna have a Hurd Christmas party this year?
Yes please! This is a great idea!
> I am an FSF member, and I have a jitsi account with them. Ravin knows how
> well jitsi works! We could talk about the cool things that the H
Hello, and happy holidays!
Every now and then, I hear someone mention potential ports of gnumach
to new architectures. I think I have heard RISC-V and (64-bit?) ARM
mentioned somewhere recently as potential new port targets. Being
involved in the x86_64 port last spring was a really fun and
intere
set EMBEDDED=yes.
Coupled with a corresponding GCC patch, this produces a toolchain that can
sucessfully build working binaries targeting aarch64-gnu.
Signed-off-by: Sergey Bugaev
---
bfd/config.bfd | 2 +-
gas/configure.tgt | 1 +
ld/configure.tgt| 5
There is currently no unwinding implementation.
Signed-off-by: Sergey Bugaev
---
libgcc/config.host | 9 +++
libgcc/config/aarch64/gnu-unwind.h | 36 +
libgcc/config/aarch64/heap-trampoline.c | 4 +--
3 files changed, 47 insertions(+), 2
The i?86-gnu target currently specifies them in
the right order, but it's easy to accidentally put them in a wrong order.
Signed-off-by: Sergey Bugaev
---
gcc/config/gnu.h | 16
gcc/config/i386/gnu.h | 11 ---
2 files changed, 16 insertions(+), 11 deletions(-)
Coupled with a corresponding binutils patch, this produces a toolchain that can
sucessfully build working binaries targeting aarch64-gnu.
Signed-off-by: Sergey Bugaev
---
gcc/config.gcc | 6 +++
gcc/config/aarch64/aarch64-gnu.h | 68
2 files
On Mon, Jan 1, 2024 at 4:02 PM Luca wrote:
> Hi Sergey,
Hi Luca,
> Really great work! To work on gnumach we just need MIG and any armv8
> compiler (also targeting GNU/Linux is fine), and it seems MIG works fine
> without adjustments? Maybe there could be some issues once it's run
> somewhere, e.
On Mon, Jan 1, 2024 at 10:21 PM Luca wrote:
> > MIG seems to just work (thanks to all the Flávio's work!). I'm using
> > the same message ABI as on x86_64, and haven't seen any issues so far
> > — neither compiler errors / failed static assertions (about struct
> > sizes and such), nor hardware er
Signed-off-by: Sergey Bugaev
---
include/mach/message.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/mach/message.h b/include/mach/message.h
index 9790ef98..87b83951 100644
--- a/include/mach/message.h
+++ b/include/mach/message.h
@@ -240,7 +240,7
And just enough of buildsystem plumbing to install them.
Signed-off-by: Sergey Bugaev
---
This should not break anything if it is applied, but I don't expect it
to get applied as is. Rather, please review and discuss.
- exception.h lists some exception codes. Particularly, we can
appar
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
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
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
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/a
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/aa
s is just something I haven't figured out a nice way to fix yet.
Sergey
P.S. I have not forgotten about my other unmerged patch series! (Most
importantly, O_IGNORE_CTTY everywhere and the fcntl fortification.) I
hope to find some time to hack on them, hopefully some time soon.
Sergey Bu
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
x27;s suggestion [0], drop the static
GLRO(dl_pagesize) initializers (for now, only if EXEC_PAGESIZE is not
defined), and don't require EXEC_PAGESIZE definition for libio to
enable mmap usage.
[0]: https://mail.gnu.org/archive/html/bug-hurd/2011-10/msg00035.html
Signed-off-by: Sergey Bugaev
--
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
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
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 lo
also what THREAD_SELF, THREAD_GETMEM, and THREAD_SETMEM macros access.
Signed-off-by: Sergey Bugaev
---
.../mach/hurd/aarch64/dl-tls-initialized.c| 19 ++
sysdeps/mach/hurd/aarch64/tls.h | 206 ++
2 files changed, 225 insertions(+)
create mode 100644 sysdeps
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/sysdep
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/li
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.
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 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
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
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 () becaus
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
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
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 klud
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
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
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, 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 pr
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
&
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 broke
On Wed, Jan 3, 2024 at 10:07 PM Luca wrote:
> Hi Sergey,
Hi,
> 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, then I reuse the i386 grub install to boot the 64 bit kernel
> with a cus
On Thu, Jan 4, 2024 at 10:57 AM Samuel Thibault wrote:
>
> 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 need
On Fri, Jan 5, 2024 at 12:52 AM Samuel Thibault wrote:
> Which kind of activity?
I just had a loop spawning /bin/true — this should've triggered it
assuming it was related to some state getting corrupted on
context-switching.
> I use
>
> while true ; do apt install --reinstall wdiff ; done
That
On Fri, Jan 5, 2024 at 2:09 AM Samuel Thibault wrote:
> This is a TODO-list of mostly not-sexy things, but that we do want to
> work on, because at some point it can be a question of survival of the
> whole Hurd ecosystem (e.g. y2038 really is a concern).
You may want to add moving off ext2 to so
I'm not seeing hurd-dbg / hurd-libs-dbg packages in your repo. Could
you please either teach me where to look, or if they're indeed
missing, upload them?
Also I can't help but notice that the hurd package (i.e the translator
binaries) is still not being built as PIE, unlike basically all the
other
On Sat, Jan 6, 2024 at 2:42 AM Luca wrote:
> I had this small patch applied that apparently is enough for me to have
> some kind of core dump, I'm not sure if it's a good solution:
> +#ifdef __x86_64__
> + struct _libc_fpstate fpstate;
> + memset(&fpstate, 0, sizeof(fpstate));
> +
On Sat, Jan 6, 2024 at 9:45 PM Samuel Thibault wrote:
>
> Luca, le sam. 06 janv. 2024 19:41:17 +0100, a ecrit:
> > Il 29/12/23 15:14, Luca Dariz ha scritto:
> > > Il 29/12/23 14:44, Samuel Thibault ha scritto:
> > > > Also, it would be useful to compile the tests with
> > > > -ftrivial-auto-var-in
On Sat, Jan 6, 2024 at 10:26 PM Luca wrote:
> Uhm, I still have an issue, although a bit different now:
>
> By the way, the exception is still the same (General Protection, which
> is usually forwarded to user space), but for a different reason,
> apparently a non-canonical address in $rax=0x8
Hello!
Those of you who made it to Joshua's belated New Year's party have
heard me mumble my way through announcing this: I have been working on
a new Hurd-based disto, based on the Alpine Linux distribution [0]!
[0] https://www.alpinelinux.org/about/
Now, before I go any further, I should say t
On Sun, Jan 21, 2024 at 10:14 PM wrote:
> I'd be happy to buy a sourcehut account for it for a year.
>
> I'd also be happy to create a website for it and host it for a year.
> We should make this email (perhaps reword it) as the website's first
> blog post.
>
> Software with which we can build a s
Hello,
On Mon, Jan 22, 2024 at 8:05 PM Peter Maydell wrote:
>
> On Thu, 18 Jan 2024 at 16:03, Manolo de Medici
> wrote:
> >
> > Compilation fails on systems where copy_file_range is already defined as a
> > stub.
>
> What do you mean by "stub" here ? If the system headers define
> a prototype f
On Mon, Jan 22, 2024 at 9:23 PM Sergey Bugaev wrote:
> call such a function. For example on GNU/Linux, remove(2) is a stub,
(That was supposed to say revoke(2), of course.)
601 - 700 of 850 matches
Mail list logo
