IDE is working, this is what I use every time I'm on hurd. It's just a bit
slower because it can't use DMA (except if you patch gnumach:
vm_allocate_contiguous to allow palign to be greater than page size but
still multiple of it)
Le jeu. 18 mai 2023 à 01:35, Damien Zammit a écrit :
> Try '-M q3
Try '-M q35' passed to qemu as this will use a newer chipset emulation that
includes AHCI controller by default. Im not sure if IDE is working at this
point.
Damien
Sent from ProtonMail mobile
Original Message
On 18 May 2023, 4:24 am, Janneke Nieuwenhuizen wrote:
> Hi!
>
> S
On Wed, May 17, 2023 at 9:25 PM Janneke Nieuwenhuizen wrote:
> Hi!
Hi,
> Here are the
> last 24 (WTF, 1980 wants their screensize back!?) lines (I don't know
> how to get the full log from QEMU):
>
> --8<---cut here---start->8---
> --8<---cut here-
Joseph Myers, le mer. 17 mai 2023 19:39:23 +, a ecrit:
> On Wed, 17 May 2023, Sergey Bugaev via Libc-alpha wrote:
>
> > Signed-off-by: Sergey Bugaev
> > ---
> > My build keeps insisting that stdc-predef.h should be next to sysdeps and
> > sys/cdefs.h; maybe it's right? If not, how do I stop i
Applied, thanks!
Sergey Bugaev, le mer. 17 mai 2023 22:14:35 +0300, a ecrit:
> strlen, which is another ifunc-selected function, is invoked during
> early static executable startup if the argv arrives from the exec
> server. Make it not crash.
>
> Checked on x86_64-gnu: statically linked executab
Applied, thanks!
Sergey Bugaev, le mer. 17 mai 2023 22:14:34 +0300, a ecrit:
> On x86_64, we have to pass function arguments in registers, not on the
> stack. We also have to align the stack pointer in a specific way. Since
> sharing the logic with i386 does not bring much benefit, split the file
Applied, thanks!
Sergey Bugaev via Libc-alpha, le mer. 17 mai 2023 22:14:33 +0300, a ecrit:
> It is illegal to call thread_get_state () on mach_thread_self (), so
> this codepath cannot be used as-is to fork the calling thread's TLS.
> Fortunately we can use THREAD_SELF (aka %fs:0x0) to find out t
Applied, thanks!
Sergey Bugaev, le mer. 17 mai 2023 22:14:32 +0300, a ecrit:
> Unlike sigstate->thread, tcb->self did not hold a Mach port reference on
> the thread port it names. This means that the port can be deallocated,
> and the name reused for something else, without anyone noticing. Using
Applied, thanks!
Sergey Bugaev, le mer. 17 mai 2023 22:14:31 +0300, a ecrit:
> ...instead of mach_setup_thread (), which is unsuitable for setting up
> function calls.
>
> Checked on x86_64-gnu: the signal thread no longer crashes upon trying
> to process a message.
>
> Signed-off-by: Sergey Bug
Applied, thanks!
Sergey Bugaev via Libc-alpha, le mer. 17 mai 2023 22:14:30 +0300, a ecrit:
> This is just like mach_setup_thread (), but it's suitable for making the
> thread call a function correctly, as opposed to explicitly setting the
> thread's stack and instruction pointers to the given val
Applied, thanks!
Sergey Bugaev via Libc-alpha, le mer. 17 mai 2023 22:14:29 +0300, a ecrit:
> Signed-off-by: Sergey Bugaev
> ---
> hurd/hurdfault.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/hurd/hurdfault.c b/hurd/hurdfault.c
> index 4340897d..dae889a9 100644
Applied, thanks!
Sergey Bugaev via Libc-alpha, le mer. 17 mai 2023 22:14:28 +0300, a ecrit:
> The existing two macros, MACHINE_THREAD_STATE_SET_PC and
> MACHINE_THREAD_STATE_SET_SP, can be used to set program counter and the
> stack pointer registers in a machine-specific thread state structure.
>
Sergey Bugaev, le mer. 17 mai 2023 22:14:27 +0300, a ecrit:
> This is a Mach-specific thread state definitions, and it's already
> handled by sysdeps/mach/thread_state.h.
?
No, this is the template file for the per-arch files, that you'd fall
down on when building for another arch, so you know wha
Applied, thanks!
Sergey Bugaev, le mer. 17 mai 2023 21:11:50 +0300, a ecrit:
> ---
>
> - all_intrs pushes FSGS using the PUSH_FSGS_ISR variant, so we have to do
> the same thing here too
> - don't forget to pop the value to load into %es
>
> x86_64/locore.S | 3 ++-
> 1 file changed, 2 insert
Joshua Branson, le mer. 17 mai 2023 15:41:01 -0400, a ecrit:
> Samuel Thibault writes:
> > I have restored some pieces which are not outdated (we still do have
> > 32-on-64
> > plans, and running 32bit on 64bit hardware is still something people
> > have to understand possible).
>
> That is tota
Samuel Thibault writes:
> Hello,
>
> I have restored some pieces which are not outdated (we still do have 32-on-64
> plans, and running 32bit on 64bit hardware is still something people
> have to understand possible).
That is totally fine with me. May I ask why we might pursue supporting
32-on-
On Wed, 17 May 2023, Sergey Bugaev via Libc-alpha wrote:
> Signed-off-by: Sergey Bugaev
> ---
> My build keeps insisting that stdc-predef.h should be next to sysdeps and
> sys/cdefs.h; maybe it's right? If not, how do I stop it from changing?
I suggest changing the generator code not to put this
This is just like mach_setup_thread (), but it's suitable for making the
thread call a function correctly, as opposed to explicitly setting the
thread's stack and instruction pointers to the given values. Internally,
it uses MACHINE_THREAD_STATE_SETUP_CALL.
Unlike mach_setup_thread (), which is ex
It is illegal to call thread_get_state () on mach_thread_self (), so
this codepath cannot be used as-is to fork the calling thread's TLS.
Fortunately we can use THREAD_SELF (aka %fs:0x0) to find out the value
of our fs_base without calling into the kernel.
Fixes: f6cf701efc61c9ad910372bda14b9a235d
On x86_64, we have to pass function arguments in registers, not on the
stack. We also have to align the stack pointer in a specific way. Since
sharing the logic with i386 does not bring much benefit, split the file
back into i386- and x86_64-specific versions, and fix the x86_64 version
to set up t
Signed-off-by: Sergey Bugaev
---
hurd/hurdfault.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hurd/hurdfault.c b/hurd/hurdfault.c
index 4340897d..dae889a9 100644
--- a/hurd/hurdfault.c
+++ b/hurd/hurdfault.c
@@ -205,8 +205,8 @@ _hurdsig_fault_init (void)
It runs
And these are the rest of my x86_64-gnu glibc fixes! (well, for now)
With these (+ the BRK_START change), I'm able build a system that boots
to /bin/sh and runs some commands (coreutils) successfully.
Enjoy :)
Sergey
Unlike sigstate->thread, tcb->self did not hold a Mach port reference on
the thread port it names. This means that the port can be deallocated,
and the name reused for something else, without anyone noticing. Using
tcb->self will then lead to port use-after-free.
Fortunately nothing was accessing
...instead of mach_setup_thread (), which is unsuitable for setting up
function calls.
Checked on x86_64-gnu: the signal thread no longer crashes upon trying
to process a message.
Signed-off-by: Sergey Bugaev
---
hurd/hurdsig.c| 10 ++
sysdeps/mach/hurd/profil.c| 5
Signed-off-by: Sergey Bugaev
---
My build keeps insisting that stdc-predef.h should be next to sysdeps and
sys/cdefs.h; maybe it's right? If not, how do I stop it from changing?
sysdeps/mach/hurd/bits/errno.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sysdeps/mach/hurd/b
strlen, which is another ifunc-selected function, is invoked during
early static executable startup if the argv arrives from the exec
server. Make it not crash.
Checked on x86_64-gnu: statically linked executables launched after the
exec server is up now start up successfully.
Signed-off-by: Serg
This is a Mach-specific thread state definitions, and it's already
handled by sysdeps/mach/thread_state.h.
Signed-off-by: Sergey Bugaev
---
sysdeps/generic/thread_state.h | 51 --
1 file changed, 51 deletions(-)
delete mode 100644 sysdeps/generic/thread_state.h
The existing two macros, MACHINE_THREAD_STATE_SET_PC and
MACHINE_THREAD_STATE_SET_SP, can be used to set program counter and the
stack pointer registers in a machine-specific thread state structure.
Useful as it is, this may not be enough to set up the thread to make a
function call, because the m
ldconfig was allocating PATH_MAX bytes on the stack for the library file
name. The issues with PATH_MAX usage are well documented [0][1]; even if
a program does not rely on paths being limited to PATH_MAX bytes,
allocating 4096 bytes on the stack for paths that are typically rather
short (strlen ("
Hello,
having set up a very basic x86_64-gnu system to debug startup issues, I
was surprised to discover that my self-built ld.so does not look for the
shared libraries in /lib/x86_64-gnu/ (which is where Samuel Thibault's deb
packages place them) at all. I then learned that ld.so.cache and ldconf
These files could be useful to any port that wants to use ld.so.cache.
Signed-off-by: Sergey Bugaev
---
sysdeps/{unix/sysv/linux => }/x86/readelflib.c | 0
sysdeps/{unix/sysv/linux => }/x86_64/dl-cache.h | 0
2 files changed, 0 insertions(+), 0 deletions(-)
rename sysdeps/{unix/sysv/linux => }
On May 17, 2023 7:49:24 PM GMT+02:00, Sergey Bugaev wrote:
>Hello,
>
>now that /bin/sh is working, I'm playing with the system a bit, and
>thought it might be interesting to share some sample output from
>various commands (I only have the Hurd itself and partly binutils
>installed):
>
># uname -a
Hi!
So, Guix's glibc-2.35 has patches for centiseconds and monotonic (and
others) that were forward ported since glibc 2.31, instead of refreshed
from upstream Debian Salsa:
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/glibc-hurd-clock_gettime_monotonic.patch
htt
---
- all_intrs pushes FSGS using the PUSH_FSGS_ISR variant, so we have to do
the same thing here too
- don't forget to pop the value to load into %es
x86_64/locore.S | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/x86_64/locore.S b/x86_64/locore.S
index 2b8e4c44..4e34186
On Wed, May 17, 2023 at 8:49 PM Sergey Bugaev wrote:
> (I only have the Hurd itself and partly binutils
> installed):
...and by binutils I mean coreutils, of course.
("Partly", because there was not enough space in the disk image, so
not all of them got unpacked successfully. And I've also got d
Hello,
now that /bin/sh is working, I'm playing with the system a bit, and
thought it might be interesting to share some sample output from
various commands (I only have the Hurd itself and partly binutils
installed):
# uname -a
GNU 0.9 GNU-Mach 1.8/Hurd-0.9 x86_64-AT386 GNU
# /bin/echo --versi
Applied, thanks!
Flavio Cruz, le mar. 16 mai 2023 23:01:01 -0400, a ecrit:
> We are checking for the existence of time_value64_t but we didn't add
> that to the task_thread_times_info structure.
> ---
> include/mach/task_info.h | 6 ++
> kern/task.c | 8 +++-
> 2 files change
Applied, thanks!
Flavio Cruz, le mar. 16 mai 2023 22:59:24 -0400, a ecrit:
> This hasn't caused any problems yet but we are passing a pointer to struct
> task_thread_times_info which can cause problems if we populate over the
> existing size of the struct.
> ---
> sysdeps/mach/clock_gettime.c | 2
Hello,
I have restored some pieces which are not outdated (we still do have 32-on-64
plans, and running 32bit on 64bit hardware is still something people
have to understand possible).
Thanks,
Samuel
jbra...@dismail.de, le mer. 17 mai 2023 09:53:01 -0400, a ecrit:
> ---
> faq/64-bit.mdwn
---
faq/64-bit.mdwn | 15 ---
open_issues/64-bit_port.mdwn | 6 +-
2 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/faq/64-bit.mdwn b/faq/64-bit.mdwn
index 2e1278cb..9c8ecc9c 100644
--- a/faq/64-bit.mdwn
+++ b/faq/64-bit.mdwn
@@ -13,11 +13,12 @@ License
40 matches
Mail list logo
