Re: It runs!

Hi, On Sat, May 13, 2023, 04:01 wrote: > > Forgive me for asking the dumb question... > > is the current 64-bit port for both the kernel and userland? Yes :) > If yes, then I will submit a patch soon to remove this paragraph from the wiki > > There are currently no plans for 64-bit userlan

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

On Sat, May 13, 2023 at 7:38 PM jbra...@dismail.de wrote: > +Hurd developers are adding 64-bit support, and they plan to drop the > +32-bit support, once the 64-bit support is deemed stable. Is this really the plan? :( Has this been discussed anywhere? I understand that supporting multiple arch

Re: It runs!

On Fri, May 12, 2023 at 9:30 PM Sergey Bugaev wrote: > But I haven't > yet been able to receive any actual output from the shell or > subsequent commands on the console. I figured it out! -- it was trying to receive the SIGCHLD, and crashing. Now it's all fixed, and signal

Re: struct sigcontext in Hurd/x86_64

On Sun, May 14, 2023 at 5:11 PM Bruno Haible wrote: > But another thing appears to be wrong: The role of sc_rsp versus sc_ursp > in glibc/sysdeps/mach/hurd/x86_64/bits/sigcontext.h. > > What glibc/sysdeps/mach/hurd/x86/trampoline.c does for x86_64 is: > > _hurd_setup_sighandler (...) > { > ... >

Re: struct sigcontext in Hurd/x86_64

Looking at [0]: 'int code' should be 'long code', otherwise you won't be able to extract the full 64-bit address from it. I don't know how this works out for the BSDs -- maybe they just don't pass the address in there? [0]: https://git.savannah.gnu.org/gitweb/?p=libsigsegv.git;a=blob;f=src/fault-

Re: [PATCH glibc] Stop checking if MiG supports retcode.

Hi, On Mon, May 15, 2023 at 7:09 AM Flávio Cruz wrote: > If we want > ./configure to check if MiG generates code to call the server reply routine > in case of errors (it doesn't :() then we will need to build a different > check. Huh? Why would MIG call that? Maybe I'm missing some context. Her

Re: [PATCH glibc] Stop checking if MiG supports retcode.

On Mon, May 15, 2023 at 9:19 AM Sergey Bugaev wrote: > On Mon, May 15, 2023 at 7:09 AM Flávio Cruz wrote: > > If we want > > ./configure to check if MiG generates code to call the server reply routine > > in case of errors (it doesn't :() then we will need to bu

[PATCH v2 1/4] exec: Allow loading x86_64 executables on x86_64

Since we don't support mixing i386 and x86_64 binaries on the same system (as running them requires different build-time gnumach configurations), the exec server can simply require the binary being loaded to have been built for the same architecture as the exec server itself. --- exec/exec.c |

[PATCH v2 3/4] proc: Don't buffer Mach console output

Normally glibc does not buffer tty output, but a devstream backed by the Mach console device cannot be isatty'ed. So we need to ask glibc explicitly to not buffer it. This is what the startup and mach-defpager do already. --- proc/main.c | 1 + 1 file changed, 1 insertion(+) diff --git a/proc/mai

[PATCH v2 2/4] proc: Report CPU_TYPE_X86_64 in uname as "x86_64"

This fixes a proc server crash during startup inside initialize_version_info (). --- proc/cpu-types.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/proc/cpu-types.c b/proc/cpu-types.c index 3d89d5a7..89787d3d 100644 --- a/proc/cpu-types.c +++ b/proc/cpu-types.c @@ -30,6 +30,9 @@ const cha

[PATCH v2 4/4] Cosmetic tweaks

--- proc/msg.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proc/msg.c b/proc/msg.c index 25ce0d5b..93ad995b 100644 --- a/proc/msg.c +++ b/proc/msg.c @@ -80,7 +80,7 @@ S_proc_setmsgport (struct proc *p, perror ("pthread_create"); } } - + r

[PATCH] x86_64: Fix reporting fsgs base in thread_get_state ()

Fixes 31dd30a94a682955c3c9e2f42252b4a07687067a "add setting gs/fsbase". --- This was breaking fork () in glibc when it tried to set up TLS in the new process by copying fs_base from an existing thread. i386/i386/pcb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/i386/i386/p

[PATCH 1/4] hurd: Fix aligning signal stack pointer

Fixes 60f9bf974694d50daf58d46347b06a5975ac5ddd "hurd: Port trampoline.c to x86_64" Checked on x86_64-gnu. Reported-by: Bruno Haible Signed-off-by: Sergey Bugaev --- sysdeps/mach/hurd/x86/trampoline.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sysdeps/mac

[PATCH 3/4] hurd: Fix sc_i386_thread_state layout

x86_64-gnu. Signed-off-by: Sergey Bugaev --- sysdeps/mach/hurd/x86/trampoline.c | 6 ++ sysdeps/mach/hurd/x86_64/bits/sigcontext.h | 8 2 files changed, 14 insertions(+) diff --git a/sysdeps/mach/hurd/x86/trampoline.c b/sysdeps/mach/hurd/x86/trampoline.c index 1f92064e

[PATCH 4/4] hurd: Fix computing user stack pointer

Fixes b574ae0a2876ee94e4fe617f878407bf818c2df0 "hurd: Implement sigreturn for x86_64" Checked on x86_64-gnu. Signed-off-by: Sergey Bugaev --- sysdeps/mach/hurd/x86_64/sigreturn.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sysdeps/mach/hurd/x86_64/sigreturn.c

[PATCH 0/4] x86_64-gnu signal fixes

Hello, now that we got enough of the system running on x86_64-gnu, we can actually test the signal machinery. In fact we sort of *have to*, because /bin/sh receives SIGCHLD when a command completes, and wants to handle it. Suprisingly, most of the logic actually does just work! -- but several thi

[PATCH 2/4] hurd: Align signal stack pointer after allocating stackframe

sizeof (*stackframe) appears to be divisible by 16, but we should not rely on that. So make sure to leave enough space for the stackframe first, and then align the final pointer at 16 bytes. Checked on x86_64-gnu. Signed-off-by: Sergey Bugaev --- sysdeps/mach/hurd/x86/trampoline.c | 5 ++--- 1

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

On Mon, May 15, 2023 at 6:12 PM Guy-Fleury Iteriteka wrote: > On May 15, 2023 4:38:34 PM GMT+02:00, "jbra...@dismail.de" > wrote: > >+As of May 2023, the Hurd developers have a bootable 64-bit Debian > Are sure a debian hurd boot?? I'm rather sure some patches required to get anything serious (

Re: [PATCH] faq/64-bit.mdwn: added up to date 64-bit porting info open_issues/64-bit_port.mdwn: added up to date 64-bit porting info

On Mon, May 15, 2023 at 7:28 PM Guy-Fleury Iteriteka wrote: > Yes, i know that. I fallow you on mastodon. Then you get to see all the shitposts :D > Also as you are good in writing you can documents how you created and launch > it but when you finished your great work Ah, :blush: thank you fo

Re: [PATCH 0/3] Rumpkernel in GNU Guix

Hi, On Tue, May 16, 2023 at 11:58 AM Janneke Nieuwenhuizen wrote: > Sadly when actually using them booting hangs: > > start: pci.arbiter: > > So, yeah. To be continued. Not that I know anything about any of this, but: * why are you passing --store-type=typed to pci-arbiter? (Bad copy-pas

Re: [PATCH glibc] Stop checking if MiG supports retcode.

On Tue, May 16, 2023 at 6:02 PM Flávio Cruz wrote: > Yes, I meant this when I said "generate code to call the server reply routine > in case of errors". Ah, I see. > Take the example of the term translator, it forces TypeCheck to be 0 so that > it can still receive replies in the error case (oth

Sample command output

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

Re: Sample command output

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

[RFC PATCH] x86_64: Attempt to fix ast_from_interrupt

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

[RFC PATCH 0/2] On ldconfig and ld.so.cache

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

[RFC PATCH 2/2] x86: Make dl-cache.h and readelflib.c not Linux-specific

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

[RFC PATCH 1/2] elf: Port ldconfig away from stack-allocated paths

-linux-gnu and i686-gnu. Signed-off-by: Sergey Bugaev --- elf/ldconfig.c | 59 +- 1 file changed, 20 insertions(+), 39 deletions(-) diff --git a/elf/ldconfig.c b/elf/ldconfig.c index 2fc45ad8..7f2e4226 100644 --- a/elf/ldconfig.c +++ b/elf/

[PATCH 02/10] mach: Define MACHINE_THREAD_STATE_SETUP_CALL

tion pointers, and also applies any machine-specific requirements to make a valid function call. The default implementation simply forwards to MACHINE_THREAD_STATE_SET_PC and MACHINE_THREAD_STATE_SET_SP, but on x86_64 we additionally align the stack pointer. Signed-off-by: Sergey Bugaev --- Any i

[PATCH 01/10] Remove sysdeps/generic/thread_state.h

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_st

[PATCH 09/10] hurd: Also make it possible to call strlen very early

: Sergey Bugaev --- sysdeps/mach/hurd/x86_64/static-start.S | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sysdeps/mach/hurd/x86_64/static-start.S b/sysdeps/mach/hurd/x86_64/static-start.S index cc8e2410..0fed375c 100644 --- a/sysdeps/mach/hurd/x86_64/static-start.S +++ b/sysdeps/mach/hurd

[RFC PATCH 10/10] hurd: Regenerate errno.h

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

[PATCH 05/10] hurd: Use __mach_setup_thread_call ()

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

[RFC PATCH 06/10] hurd: Make sure to not use tcb->self

d stack for the main thread, and just exit __pthread_setup early in this case. Found upon attempting to use tcb->self and getting unexpected crashes. Signed-off-by: Sergey Bugaev --- sysdeps/mach/hurd/i386/tls.h | 3 +-- sysdeps/mach/hurd/x86/htl/pt-setup.c | 34 ++-

[PATCH 00/10] Stack setup & misc fixes for x86_64-gnu

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

[PATCH 03/10] hurd: Use MACHINE_THREAD_STATE_SETUP_CALL

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

[PATCH 08/10] hurd: Fix setting up pthreads

4-gnu" Signed-off-by: Sergey Bugaev --- __thread_set_pcsptp is also used by pthread_cancel (), which suffers from the same issue. Eventually I'd like to remove __thread_set_pcsptp entirely. .../mach/hurd/{x86 => i386}/htl/pt-setup.c| 2 +- sysdeps/mach/hurd/x86_64/htl/pt-

[PATCH 07/10] hurd: Fix x86_64 _hurd_tls_fork

Fixes: f6cf701efc61c9ad910372bda14b9a235db310a8 "hurd: Implement TLS for x86_64" Checked on x86_64-gnu: fork () now works! Signed-off-by: Sergey Bugaev --- It would be nice if GNU Mach allowed thread_get_state (mach_thread_self (), i386_FSGS_BASE_STATE) like it already allows thread_set_state for this case. But even

[PATCH 04/10] mach: Add __mach_setup_thread_call ()

, which is exported via mach.h for the benefit of the Hurd exec server, __mach_setup_thread_call () is private to glibc for the time being. Signed-off-by: Sergey Bugaev --- mach/mach.h | 6 +- mach/setup-thread.c | 52 - mach/setup-thr

Re: Some progress, Guix rumpdisk still crashes...

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-

Re: Guix hurd with rumpdisk boots! [WAS Re: Some progress, Guix rumpdisk still crashes...]

On Thu, May 18, 2023 at 11:07 AM Janneke Nieuwenhuizen wrote: > Now that was really a great help, thanks! > > Ah, I had no idea; this is so helpful. Maybe a good idea to have this > on the website/wiki, right? Glad I was able to help :D > Is there a way to pass the "console=com0" argument from

[PATCH 1/2] streamio: Implement trivfs_append_args ()

This enables me to run 'fsysopts /dev/mach-console' and get: /hurd/streamio --writable console --- trans/streamio.c | 39 +++ 1 file changed, 39 insertions(+) diff --git a/trans/streamio.c b/trans/streamio.c index 2d40a5d3..272a002c 100644 --- a/trans/streamio

[PATCH 2/2] Remove an unused include

--- utils/ps.c | 1 - 1 file changed, 1 deletion(-) diff --git a/utils/ps.c b/utils/ps.c index a852b92f..6a08f736 100644 --- a/utils/ps.c +++ b/utils/ps.c @@ -21,7 +21,6 @@ #include #include #include -#include #include #include #include -- 2.40.1

Re: [RFC PATCH 06/10] hurd: Make sure to not use tcb->self

Hello, On Thu, May 18, 2023 at 9:55 PM Joseph Myers wrote: > > I suspect this of causing linknamespace test failures: > > Contents of conform/POSIX2008/pthread.h/linknamespace.out: > > [initial] pthread_create -> [libpthread.a(pt-create.o)] __pthread_setup -> > [libpthread.a(pt-setup.o)] hurd_th

Re: [PATCH glibc] Stop checking if MiG supports retcode.

Hi, On Fri, May 19, 2023 at 9:43 AM Flávio Cruz wrote: > I have made changes so that it does daily builds and I'm able to boot small > programs. However, I haven't had the time to boot programs built against > Glibc. How do you package and boot the static binaries using a ramdisk? I've > been

Re: [RFC PATCH 06/10] hurd: Make sure to not use tcb->self

On Thu, May 18, 2023 at 11:16 PM Joseph Myers wrote: > Strictly there are two separate issues: (a) calling an exported symbol > should be done via a hidden alias, to avoid going via the PLT, and (b) > functions in a standard namespace should not call names in the user's > namespace, which requires

Re: Guix hurd with rumpdisk boots! [WAS Re: Some progress, Guix rumpdisk still crashes...]

On Fri, May 19, 2023 at 1:20 PM Janneke Nieuwenhuizen wrote: > Okay, yeah I tried > > --8<---cut here---start->8--- > guix shell qemu -- qemu-system-i386 \ > -m 4096 \ > --enable-kvm

Re: [RFC PATCH 0/2] On ldconfig and ld.so.cache

Hello, On Fri, May 19, 2023 at 3:30 PM Florian Weimer wrote: > Debian hasn't upstreamed there multi-arch path layouts. We could > implement multi-arch ldconfig in /etc/ld.so.cache, but with the paths > that Debian currently uses, it's not easy because there's no automated > way ldconfig can reco

[PATCH] hurd: Fix using interposable hurd_thread_self

Create a private hidden __hurd_thread_self alias, and use that one. Fixes 2f8ecb58a59eb82c43214d000842d99644a662d1 "hurd: Fix x86_64 _hurd_tls_fork" and c7fcce38c83a2bb665ef5dc4981bf20c7e586123 "hurd: Make sure to not use tcb->self" Reported-by: Joseph Myers Signe

[PATCH] hurd: Fix __TIMESIZE on x86_64

We had sizeof (time_t) == 8, but __TIMESIZE == 32. Signed-off-by: Sergey Bugaev --- ...oops. I have not tested whether this breaks anything (other then checking that it still builds), but it's kind of amazing that it had worked at all before this, and there's a higher chance of t

Re: Sample command output

Hello, On Sat, May 20, 2023 at 11:53 AM Samuel Thibault wrote: > Luca, le sam. 20 mai 2023 10:07:26 +0200, a ecrit: > > What is the limitation with the ramdisk size? > > It's basically about the RAM size. So if you want a larger initrd, give > more ram :) I've tried to increase the ramdisk size

[PATCH 1/3] hurd: Use __hurd_fail () instead of assigning errno

marked with the cold attribute, telling the compiler that this codepath is unlikely to be executed. In one case, use __hurd_dfail () over the plain __hurd_fail (). Signed-off-by: Sergey Bugaev --- hurd/alloc-fd.c | 13 + hurd/fopenport.c

[PATCH 3/3] io: Fix a typo

Fixes 85f7554cd97e7f03d8dc66278653045ef63a2221 "Add test case for O_TMPFILE handling in open, openat" Signed-off-by: Sergey Bugaev --- io/tst-open-tmpfile.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/io/tst-open-tmpfile.c b/io/tst-open-tmpfile.c inde

[PATCH 2/3] htl: Use __hurd_fail () instead of assigning errno

Signed-off-by: Sergey Bugaev --- *Technically*, sysdeps/htl/ is not Hurd-specific (unlike, say, sysdeps/hurd/htl), but I don't think this distinction is meaningful, and the H in HTL must stand for something. Still, this is in a separate patch so it can be (not) applied easily. sysdeps/ht

Re: [RFC PATCH 1/2] elf: Port ldconfig away from stack-allocated paths

b64/libc.so.6") is 16) is wasteful and dangerous. [0]: https://insanecoding.blogspot.com/2007/11/pathmax-simply-isnt.html [1]: https://eklitzke.org/path-max-is-tricky Instead, make use of asprintf to dynamically allocate memory of just the right size on the heap. Reviewed-by: Adhemerval Zanella

Re: [PATCH] Updated information about the rump kernels, and included a guide on how to use them on the Debian qemu image.

Hi, On Mon, May 22, 2023 at 6:49 PM jbra...@dismail.de wrote: > +upgrade to the bleeding edge Debian GNU/Hurd: > + > + $ wget > http://ftp.de.debian.org/debian/pool/main/d/debian-ports-archive-keyring/debian-ports-archive-keyring_2023.02.01_all.deb > + # dpkg -i debian-ports-archive-keyr

Re: [PATCH] * hurd/translator/httpfs.mdwn: added a link to sitemaps.org.

On Mon, May 22, 2023 at 6:50 PM jbra...@dismail.de wrote: > +- Teach httpfs to check if the computer has an internet connection at > + startup and during operation. The translator causes 30 second > + pauses on commands like "ls", when the internet is down. It is > + probably better to teach

Re: 64bit startup

Hello, On Fri, May 26, 2023 at 4:32 AM Samuel Thibault wrote: > I'm trying to start a 64bit Debian/Hurd but this fails very early. > > 0x8107a712 is the *read_exec call in exec_load, which does > happen fine, until read_exec calls copyout, which thus apparently fails > somehow. > > Does t

Re: 64bit startup

On Fri, May 26, 2023 at 12:57 PM Samuel Thibault wrote: > > And the addresses seem well above the 4 GB limit; > > Which addresses? These ones: > 0x8107a712(0,8101d463,400ee0,8101d49c,0) > 0x8106ff27(de739868,8101d463,de736fb8,0,8104ceec Le

Re: 64bit startup

On Fri, May 26, 2023 at 1:10 PM Sergey Bugaev wrote: > Let me actually try building w/ Luca's patches myself and seeing if > that works for me. Yes, still works here with the latest gnumach, so Luca's changes are not to blame. I can reproduce your crash with your gnumach build t

Re: 64bit startup

On Fri, May 26, 2023 at 2:15 PM Samuel Thibault wrote: > It does load, but stays stuck when starting ext2fs: > >start ext2fs: Yes, I can reproduce this with your build of ext2fs.static Unfortunately there are no symbols (maybe you could teach me how to fetch and load separate debuginfo into

Re: [PATCH glibc] Stop checking if MiG supports retcode.

On Fri, May 26, 2023 at 3:00 PM Flávio Cruz wrote: > Hi Sergey Hi, > Thanks for the instructions. I was able to make it work and pushed my changes > to Github. That's awesome news -- thank you! (Well, I figured as much from looking at the GitHub, but it's nice to get a confirmation.) What we

Re: 64bit startup

On Fri, May 26, 2023 at 2:15 PM Samuel Thibault wrote: > Here it is: > > https://dept-info.labri.fr/~thibault/tmp/gnumach > > It's master 377a9387cec7d4bdd6739d3bcc03f77f524adc69 with a busy-loop on > the stop_bootstrap variable at the very beginning of bootstrap_create. > No lines added/removed i

Re: 64bit startup

On Fri, May 26, 2023 at 7:22 PM Samuel Thibault wrote: > I.e. gnumach without optimizations gets things wrong. We do want to fix > that :) Or, we could also shrug it off and do what glibc is doing: #ifndef __OPTIMIZE__ # error "gnumach cannot be compiled without optimization" #endif :) :) :) :)

Re: [Guix] netdde setup confusion

On Fri, May 26, 2023 at 8:19 PM Janneke Nieuwenhuizen wrote: > Hi! Hi, > I'm trying to get netdde to work in Guix without much success. > Here is what I've added for netdde and what Guix looks like: > > --8<---cut here---start->8--- > # showtrans /dev/eth0 >

Re: 64bit startup

On Fri, May 26, 2023 at 7:22 PM Samuel Thibault wrote: > I.e. gnumach without optimizations gets things wrong. We do want to fix > that :) Dumping what I've been able to debug (so far): The crash indeed happens when loading the executable image, inside copyout (). The addresses/sizes are all fin

Re: 64bit startup

Hello! On Sun, May 28, 2023 at 12:13 AM Samuel Thibault wrote: > > task /bin/bash(1) decreasing a bogus port 82650 by 1, most probably a bug. > > bash: ../sysdeps/mach/hurd/mig-reply.c:84: __mig_dealloc_reply_port: > > Unexpected error: (os/kern) invalid name. > > > > the console warning is expe

Re: 64bit startup

On Sun, May 28, 2023 at 2:16 PM Samuel Thibault wrote: > ATM I'm seeing various issues, like __dir_lookup telling me it got its > stack smashed. Which probably rather means that the stack_guard gets > overwritten somehow. Yes, that's probably what's going on. I'll look into it, thanks. > > And o

Re: 64bit startup

scope / level of indentation). It's untested, but it builds and the generated code looks OK (sc_reply_port gets loaded straight into %rdx, to be passed into __sigreturn2). Please test! The stack guard issue must be caused by something else. Sergey -- >8 -- From: Sergey Bugaev Subject: [PATC

Re: 64bit startup

On Sun, Jun 4, 2023 at 8:21 PM Samuel Thibault wrote: > It seems so indeed. But it's not only the stack guard, but various TLS > accesses. What would be an easy way for me to reproduce this? Sergey

[PATCH] hurd: Exclude more headers when generating errno.h

This both works around ordering issues, and removes an x86-specific file from the list. Suggested-by: Joseph Myers Signed-off-by: Sergey Bugaev --- We could maybe clean this up even further, but -- diminishing returns :| sysdeps/mach/hurd/bits/errno.h | 4 sysdeps/mach/hurd/errnos.awk

[PATCH v3 0/2] O_IGNORE_CTTY everywhere

rd has its own version of check_fds.c anyway, which already does the right thing wrt cttys. With this, the patchset is quite small and manageable again. I'm still interested in whether there could be a way to pass O_IGNORE_CTTY when using fopen () too -- but that doesn't have to block this patc

[PATCH v3 1/2] include/fcntl.h: Define O_IGNORE_CTTY

commit will actually make use of O_IGNORE_CTTY throughout the glibc codebase. Signed-off-by: Sergey Bugaev --- include/fcntl.h | 15 +++ 1 file changed, 15 insertions(+) diff --git a/include/fcntl.h b/include/fcntl.h index be435047..d788db2e 100644 --- a/include/fcntl.h +++ b/include

[PATCH v3 2/2] Use O_IGNORE_CTTY where appropriate

* getpt, openpty: Opening an unused pty, which can't be our ctty * shm_open, sem_open: These don't work with ttys * opendir: Directories are unlikely to be ttys Signed-off-by: Sergey Bugaev --- catgets/open_catalog.c | 4 ++-- elf/dl-load.c | 2 +- elf

Re: [PATCH v3 2/2] Use O_IGNORE_CTTY where appropriate

Hello, On Mon, Jun 5, 2023 at 12:28 PM Florian Weimer wrote: > > * shm_open, sem_open: These don't work with ttys > > * opendir: Directories are unlikely to be ttys > > I scrolled through the patch, and it seems to me that all these open > calls could use O_NOCTTY. Perhaps they could use O_NOCTT

Re: 64bit startup

On Mon, Jun 5, 2023 at 2:05 PM Samuel Thibault wrote: > I can easily trigger crashes with > > fsysopts / --writable > while true ; do ps-hurd -feMj > /tmp/blip ; done That is going to be much easier to debug than debootstrap, thank you! Sergey

Re: [PATCH v3 2/2] Use O_IGNORE_CTTY where appropriate

Hello, On Mon, Jun 5, 2023 at 11:58 PM Paul Eggert wrote: > > On 2023-06-04 13:42, Sergey Bugaev via Libc-alpha wrote: > > - int flags = O_RDONLY | O_NONBLOCK | O_DIRECTORY | O_CLOEXEC; > > + int flags = O_RDONLY | O_NONBLOCK | O_DIRECTORY | O_CLOEXEC | > > O

Re: 64bit startup

On Mon, Jun 5, 2023 at 3:03 PM Sergey Bugaev wrote: > That is going to be much easier to debug than debootstrap, thank you! Unfortunately I'm facing some troubles :| For one thing you seem to have rebuilt/updated the packages, but not the rootfs image, so now the debuginfo I download

Re: 64bit startup

On Tue, Jun 6, 2023, 23:56 Luca wrote: > yes this makes perfectly sense, I think I'm chasing the same bug currently, > or some variation of it. With some tracing I saw that this corruption seems > to happen when an irq (usually timer) fires when returning from a trap, > although not necessarily

Re: [PATCH v3 1/2] include/fcntl.h: Define O_IGNORE_CTTY

Hello, On Mon, Jun 5, 2023 at 9:25 PM Adhemerval Zanella Netto wrote: > We currently are trying to avoid the > "#ifdef ...", so a code that does not define, where is should, would fail > at compile time. Yes, this makes perfect sense, and it was something I was also slightly concerned about (wha

fsbase getting clobbered (was: Re: 64bit startup)

On Wed, Jun 7, 2023 at 12:15 AM Sergey Bugaev wrote: > If my theory is correct, what we actually do wrong is assuming that > the fsbase value located on the (PCB) stack beyond the %rsp will not > spontaneously change; but in absence of a red zone that's just not > true — anythin

Re: 64bit startup

Hello, with the following hacky patch, I no longer see any crashes, debootstrap --second-stage runs all the way and leaves me with an almost full Debian GNU/Hurd x86_64 system \o/ Well, debootstrap does output lots of errors like dpkg: dependency problems prevent configuration of openssh-server:

Re: [PATCH v3 2/2] Use O_IGNORE_CTTY where appropriate

Hello -- that is a much more positive response than I was expecting to get! Thank you! On Fri, Jun 9, 2023 at 9:37 PM Paul Eggert wrote: > You could change the documentation so that it now says that flags that > imply O_IGNORE_CTTY are also meaningful. That should be fine. Perhaps... but there's

Re: notes for 2023 release

Hello, On Sat, Jun 10, 2023 at 12:47 PM Samuel Thibault wrote: > Do you think about anything else to announce? Not an announcement, but please consider backporting 346b6eab3c14ead0b716d53e2235464b822f48f2 "hurd: Run init_pids () before init_dtable ()" if it's not too late (or doing it after rele

Re: [PATCH v3 2/2] Use O_IGNORE_CTTY where appropriate

Hello, On Sat, Jun 10, 2023 at 12:36 AM Paul Eggert wrote: > > Do you perhaps mean that POSIX does not require a > > newly opened terminal to become your ctty even if you don't pass > > O_NOCTTY? > > Yes, that's right. The openat rationale mentions this topic. do you mean this?: "The O_NOCTTY f

Re: notes for 2023 release

On Sun, Jun 11, 2023 at 2:52 PM Samuel Thibault wrote: > > This was an important fix; currently ctty handling is completely > > broken in Debian. > > How does it manifest in practice? A background process that tries to read (or write, if TOSTOP is set, which you can do with 'stty tostop') the ter

Re: [PATCH v3 2/2] Use O_IGNORE_CTTY where appropriate

Hello, On Sun, Jun 11, 2023 at 7:54 AM Paul Eggert wrote: > OK, I'm starting to see the distinction now. So you did misunderstand it! That means not only is the explanation in the glibc manual (reproduced below) unclear, but my previous attempts to describe it and its differences to O_NOCTTY wer

Re: [PATCH v3 1/2] include/fcntl.h: Define O_IGNORE_CTTY

Hello, On Mon, Jun 12, 2023 at 9:56 PM Adhemerval Zanella Netto wrote: > > Do you think the Linux port should define O_IGNORE_CTTY to O_NOCTTY > > and not to 0? > > Hurd O_IGNORE_CTTY and Linux O_NOCTTY do not have the *exactly* semantic, > so I think we should avoid change the internal open flag

Everything's broken (was: Debian GNU/Hurd 2023 released!)

Hello -- and congratulations to all involved! Unfortunately the released installation ISO is very broken :( , which spoils the whole thing. Once you install it and try to boot for the first time, you are greeted with a wall of errors about /dev//tty1 (yes, with a double slash) and the other ttys

Re: Everything's broken (was: Debian GNU/Hurd 2023 released!)

On Wed, Jun 14, 2023 at 4:14 PM Samuel Thibault wrote: > ?? I'm not getting such a result at all of course. How did you run the > installation *exactly*? The image I downloaded was debian-sid-hurd-i386-NETINST-1.iso from [0] [0]: https://cdimage.debian.org/cdimage/ports/hurd-i386/12.0/debian-si

Re: libdiskfs assertion failed

On Wed, Jun 14, 2023, 20:38 Joshua Branson wrote: > Then I added this line above line 107 in extfs: > ../../libdiskfs/disk-pager.c > > if (scp->sc_error != EKERN_MEMORY_ERROR) > fprintf(stderr, "error %d\n", scp->sc_error); > > Then I build the hurd via > cd hurd-09.git/ > dpkg-buildpackage -u

Re: Everything's broken (was: Debian GNU/Hurd 2023 released!)

On Thu, Jun 15, 2023 at 2:14 AM Samuel Thibault wrote: > > Well, if there was, say, a call for pre-release testing, > > Well, Debian did ask for testing. > > I guess I should explicitly tell debian-hurd@ "hey that's a matter for > *us* too". I don't think I understand what you mean; but what I me

[VERY RFC PATCH] x86_64: Rework storing segment registers

* For USER32, don't store fs/gs base at all * For !USER32, store fs/gs base outside of the PCB stack * For !USER32, don't store or touch es, ds, fs, gs (but keep ss and cs) * For !USER32, disable all of the v86 code --- So I went ahead and just made x86_64 !USER32 not store or access those segment

Re: [VERY RFC PATCH] x86_64: Rework storing segment registers

On Thu, Jun 15, 2023 at 6:00 PM Samuel Thibault wrote: > > debootstrap is still not quite happy. I've uploaded the log here: [0] > > > > [0]: https://paste.gg/p/anonymous/c976008dc38342cd963b0778586ead19 > > Which part seems problematic? All those warnings, but these in particular: --- dpkg: war

Re: [VERY RFC PATCH] x86_64: Rework storing segment registers

On Thu, Jun 15, 2023 at 8:02 PM Luca wrote: > That's a bit strange, with my kernel I can now successfully end the > second stage, and without these warnings. Strangely, I don't see the > "Setting up translators: " line... Check /debootstrap/debootatrap.log :) The output I posted was from both de

[PATCH] Fix copying in MACH_PORT_DEAD on x86_64

We need to properly convert MACH_PORT_NAME_DEAD (which is 32-bit -1) into IO_DEAD, which is 64-bit -1. To reproduce: $ portinfo -va 1 (see the Mach crash trying to access a port at 0x) --- ipc/ipc_kmsg.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/ipc/ipc_k

Re: [PATCH v3 2/2] Use O_IGNORE_CTTY where appropriate

Hello, On Wed, Jun 14, 2023 at 8:40 AM Paul Eggert wrote: > The first-quoted sentence is confusing and arguably wrong. If the named > file is the process's existing controlling terminal, it will continue to > be recognized as the controlling terminal. Thanks, I can see how that can sound confusi

[PATCH] Remove error procedure directives

Back in the wonderful old days of Mach 2, when there were no send-once rights, dead names, or port reference counts, MIG used to have more kinds of operations: there were functions, procedures, simpleprocedures, routines, and simpleroutines. Routines returned an error code as their C function retur

Re: [PATCH v3 2/2] Use O_IGNORE_CTTY where appropriate

Hello, On Mon, Jun 19, 2023 at 12:55 AM Samuel Thibault wrote: > > Samuel, what do you think? > > It looks better to me to add a shared helper that adds O_IGNORE_CTTY > whenever the flags contain something that implies it. Callers of > _hurd_intern_fd / _hurd_port2fd can then easily use it That'

SSE registers in thread state

Hello, it occurred to me that as far as userland is concerned, the FPU/SEE thread state only consists of i386_fp_save & i386_fp_regs, and userland simply uses frstor to restore it when sigreturning. It seems that gnumach has grown better support for the fancier SSE registers in its internal state

Re: SSE registers in thread state

On Tue, Jun 20, 2023 at 12:24 PM Samuel Thibault wrote: > > I don't know much about SSE and those registers and fxsave/fxrstor and > > xsave/xrstor, but it seems clear enough that this will result in > > string operations breaking after a thread receives a signal > > AIUI the problem only happens

<    1   2   3   4   5   6   7   8   9   >