Signed-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/{i386 => x86}/trampoline.c | 158 ++-
1 file changed, 151 insertions(+), 7 deletions(-)
rename sysdeps/mach/hurd/{i386 => x86}/trampoline.c (68%)
diff --git a/sysdeps/mach/hurd/i386/trampoline.c
b/sysdeps/mach/hu
On Mon, Apr 3, 2023 at 10:02 PM H.J. Lu wrote:
> Or something like this.
Or like that, yeah!
On a second thought, I actually like Samuel's idea (ifdef MAP_32BIT):
instead of only building this piece of code when the tunable *is*
defined, we'd build it when the tunable *should be* defined (that i
Hi — thank you for working on this!
I have something like this applied locally, but it's intermixed with
the other 64-bit changes. So since you're submitting this now, let's
go with your version.
Just a few suggestions:
On Fri, Apr 7, 2023, 08:17 Flavio Cruz wrote:
> diff --git a/boot/boot.c b/
On Mon, Apr 10, 2023, 21:39 Samuel Thibault wrote:
>
> Hello,
>
> Applied, thanks!
Yay! Thank you for finding the time to review some more patches!
Here's to hoping that the rest will follow.
> Note that I have pushed sysdeps/mach/hurd/x86_64/sys/ucontext.h to
> sysdeps/x86_64/sys/ucontext.h sin
On Mon, Apr 10, 2023 at 9:58 PM Samuel Thibault wrote:
>
> Sergey Bugaev, le dim. 19 mars 2023 18:09:59 +0300, a ecrit:
> > +#ifdef __USE_GNU
> > +/* Number of each register in the `gregset_t' array. */
> > +enum
> > +{
> > + REG_GSFS = 0,
On Mon, Apr 10, 2023 at 10:20 PM Samuel Thibault
wrote:
>
> Sergey Bugaev, le dim. 19 mars 2023 18:09:43 +0300, a ecrit:
> > As for sigreturn specifically: I'm concerned about the possibility that
> > putting the register dump onto the user's stack (or at %rsp -
On Mon, Apr 10, 2023 at 10:04 PM Samuel Thibault
wrote:
> Sergey Bugaev, le lun. 03 avril 2023 14:56:21 +0300, a ecrit:
> > @@ -110,6 +132,10 @@ _hurd_setup_sighandler (struct hurd_sigstate *ss,
> > const struct sigaction *action
> > ucontext_t *uctxp;
On Mon, Apr 10, 2023 at 10:22 PM Samuel Thibault
wrote:
>
> Sergey Bugaev, le lun. 10 avril 2023 22:13:06 +0300, a ecrit:
> > On Mon, Apr 10, 2023 at 9:58 PM Samuel Thibault
> > wrote:
> > >
> > > Sergey Bugaev, le dim. 19 mars 2023 18:09:59 +0300
On Tue, Apr 11, 2023 at 1:03 AM Samuel Thibault wrote:
> I tend to be very cautious with reply port reuse since it can confuse
> servers a lot when e.g. interrupted, so it's generally safer not to try
> to reuse them.
Huh? Confuse how?
For one thing, the servers are unable to even tell if two se
On Tue, Apr 11, 2023 at 1:07 AM Samuel Thibault wrote:
> I believe we still want to use
>
> mach_port_t port = get_reply_port();
>
> because the caller might not know whether its port is still valid
> or not, e.g. when a signal interrupted the RPC and thus we had to
> deallocate the reply port to
On Tue, Apr 11, 2023 at 1:50 AM Samuel Thibault wrote:
> Sergey Bugaev, le dim. 02 avril 2023 15:22:33 +0300, a ecrit:
> > I propose the following: before resetting the exception port, glibc
> > would fetch the previous one, and if it's non-null, it will perform a
> >
sting, it wasn't comprehensive. I was happy
to see it pushed, but that's because I assumed that you have verified
that my assumptions & reasoning are sound and that this change doesn't
break anything. Please don't just blindly trust me with this patchset!
> Sergey Bugaev, l
On Tue, Apr 11, 2023 at 11:15 PM Samuel Thibault
wrote:
>
> Sergey Bugaev, le mar. 11 avril 2023 10:44:17 +0300, a ecrit:
> > On Tue, Apr 11, 2023 at 1:03 AM Samuel Thibault
> > wrote:
> > > I tend to be very cautious with reply port reuse since it can confuse
&
On Wed, Apr 12, 2023 at 12:23 AM Samuel Thibault
wrote:>
> Sergey Bugaev, le mar. 11 avril 2023 23:27:35 +0300, a ecrit:
> > On Tue, Apr 11, 2023 at 9:57 PM Samuel Thibault
> > wrote:
> > > Had you actually tested it on i386? It seems to be breaking the
> >
On Wed, Apr 12, 2023 at 12:00 PM Samuel Thibault
wrote:
> Was that tst-spawn6?
I can't point out any specific one :( There is just this huge wall of
output, and then the whole thing breaks / hangs. FWIW, the last lines
before my SSH / network stack died were: (Gmail is surely going to
wrap this,
Samuel, could you please either push this MIG change to Debian, or
un-push gnumach's "Delete include/mach/msg_type.h"?
I was gullible enough to 'apt upgrade' gnumach-dev, and now I cannot
build glibc anymore, getting:
/home/sergey/glibc/build/mach/RPC_task_create_rpc.c:13:10: fatal
error: mach/ms
On Wed, Apr 12, 2023 at 3:06 PM Samuel Thibault wrote:
>
> Sergey Bugaev, le mer. 12 avril 2023 14:39:55 +0300, a ecrit:
> > Samuel, could you please either push this MIG change to Debian,
>
> Isn't it there already with version 1.8+git20221221-3?
Aha! Apparently yes,
On Wed, Apr 12, 2023 at 1:45 PM Samuel Thibault wrote:
>
> Sergey Bugaev, le mer. 12 avril 2023 13:42:50 +0300, a ecrit:
> > > You can run on master to get the list of current expected failures.
> >
> > But that's the thing, I can not :|
>
> I meant after
Wow, this is great, thank you! You've really gone above and beyond
compared to what I expected you to do.
Some replies below; will reply to other points later.
On Thu, Apr 13, 2023 at 2:47 AM Samuel Thibault wrote:
> > Maybe you're building with some flags that affect this? I'm only doing
> > ..
THREAD_SETMEM directly, avoiding possible
miscompilations.
Signed-off-by: Sergey Bugaev
---
Changes since v1:
* Only deallocate the port in __mig_dealloc_reply_port if it's the same
as the stored port, because of signals.
* Add a comment detailing the reasoning.
* Add two assertions: tha
Alright, here's some more analysis.
I was unable to fetch your core dump (403), but the test case and
libc/ld all 200'ed, and the crash / hang reproduces -- awesome.
and guess what? Firstly, the error we get from mach_port_mod_refs is
EMACH_RCV_INVALID_NAME 268451842 (ipc/rcv) invalid name
so my
On Thu, Apr 13, 2023 at 4:12 PM Samuel Thibault wrote:
at ../sysdeps/mach/hurd/dl-sysdep.c:241
> 241 __mig_dealloc_reply_port (MACH_PORT_NULL);
Uhh, who deallocs a reply port like that :| You can't pass random crap
into __mig_dealloc_reply_port and rely on its particular
implementation,
On Fri, Apr 14, 2023 at 12:47 AM Samuel Thibault
wrote:
> #10 0x0106bc20 in __libc_assert_fail (assertion=0x1222762 "port == arg",
> file=0x121c2a0 "../sysdeps/mach/hurd/mig-reply.c", line=92,
> function=0x121c2c4 <__PRETTY_FUNCTION__.0> "__mig_dealloc_reply_port")
> at __libc_assert_f
On Fri, Apr 14, 2023 at 11:39 AM Samuel Thibault
wrote:
> Sergey Bugaev, le ven. 14 avril 2023 11:29:37 +0300, a ecrit:
> > But secondly, if we are not destroying the user's reply port, but
> > restoring it, then I don't think the "port = MACH_PORT_NULL, arg =
>
On Fri, Apr 14, 2023 at 12:12 PM Samuel Thibault
wrote:
> Sergey Bugaev via Libc-alpha, le ven. 14 avril 2023 11:53:43 +0300, a ecrit:
> > It's in _hurdsig_abort_rpcs, if the interrupt_operation call fails.
> >
> > Let's maybe not do that either? We're alre
d-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/i386/sigreturn.c | 35 --
1 file changed, 23 insertions(+), 12 deletions(-)
diff --git a/sysdeps/mach/hurd/i386/sigreturn.c
b/sysdeps/mach/hurd/i386/sigreturn.c
index 4f196710..a0fc8891 100644
--- a/sysdeps/mach/hurd/i386/sig
Signed-off-by: Sergey Bugaev
---
I'll understand if this patch will be rejected, since this is not a hot path.
But I just couldn't help myself when I saw what this was being compiled to!
Much cleaner now.
If you don't like THREAD_GETMEM (THREAD_SELF, _hurd_sigstate)
_hurd_thread_sigstate () already handles finding an existing sigstate
before allocating a new one, so just use that. Bonus: this will only
lock the _hurd_siglock once.
Signed-off-by: Sergey Bugaev
---
hurd/catch-exc.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a
Signed-off-by: Sergey Bugaev
---
This supersedes the previous version of this patch, and contains the same
improvements the last two patches made to the i386 version.
sysdeps/mach/hurd/x86_64/sigreturn.c | 166 +++
1 file changed, 166 insertions(+)
create mode 100644
Signed-off-by: Sergey Bugaev
---
hurd/catch-exc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/hurd/catch-exc.c b/hurd/catch-exc.c
index d375bf67..bec850f9 100644
--- a/hurd/catch-exc.c
+++ b/hurd/catch-exc.c
@@ -35,6 +35,7 @@ _S_catch_exception_raise (mach_port_t port,
#endif
On Fri, Apr 14, 2023 at 8:34 PM Samuel Thibault wrote:
> Reapplied on top of "Remove __hurd_local_reply_port", thanks!
Awesome, thank you!
I have implemented the changes we talked about (replacing the receive
right with a dead name...), and they even seem to pass the few tests
from the testsuite
On Fri, Apr 14, 2023 at 8:33 PM Samuel Thibault wrote:
> Applied with fixing the __mig_dealloc_reply_port(NULL) cases, thanks!
By the way: that __mig_dealloc_reply_port () inside
_dl_sysdep_start_cleanup () is not doing what the author of that code
wanted it to do. It deallocates the current repl
On Sat, Apr 15, 2023 at 9:45 AM Samuel Thibault wrote:
> Sergey Bugaev, le ven. 14 avril 2023 23:29:51 +0300, a ecrit:
> > By the way: that __mig_dealloc_reply_port () inside
> > _dl_sysdep_start_cleanup () is not doing what the author of that code
> > wanted it to do. It de
Hello!
Here are some assorted thoughts on cttys (controlling terminals).
Running rpctrace on any simple program, I see this:
13<--33(pid1354)->term_getctty () = 04<--39(pid1354)
task16(pid1354)->mach_port_deallocate (pn{ 10}) = 0
13<--33(pid1354)->term_open_ctty (0 0) = 0x4016 (Inva
ctty port we already
have. This means we do 1 RPC instead of 3 (and create a single protid
on the server side) if the file is our ctty, and no RPCs instead of 1
if it's not. A clear win!
Signed-off-by: Sergey Bugaev
---
hurd/dtable.c | 46 +++---
1 fi
_proc_subinit hook in the correct place --
just after _hurd_portarray is set up (so the proc server port is
available in its usual place) and just before running _hurd_subinit.
Fixes 1ccbb9258eed0f667edf459a28ba23a805549b36
("hurd: Notify the proc server later during initialization").
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/recv.c | 3 ++-
sysdeps/mach/hurd/recvfrom.c | 3 ++-
sysdeps/mach/hurd/recvmsg.c | 3 ++-
sysdeps/mach/hurd/sendmsg.c | 5 +++--
sysdeps/mach/hurd/sendto.c | 2 +-
5 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/sysdeps
another thread of the same process calling
(fork and then) exec at the same time.
This flag is already supported on Linux and FreeBSD. The flag's value,
0x4, is choosen to match FreeBSD's.
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/bits/socket.h | 5 -
sysdeps/mach/hurd
Signed-off-by: Sergey Bugaev
---
This is an attempt to write a test, roughly based on
sysdeps/unix/sysv/linux/tst-scm_rights.c
Please tell me if this needs any changes. For instance, I opted to do
my own error checking for sendmsg/recvmsg/socketpair, but I could've
alternatively added xse
ned-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/recvmsg.c | 3 +--
sysdeps/mach/hurd/sendmsg.c | 4 ++--
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/sysdeps/mach/hurd/recvmsg.c b/sysdeps/mach/hurd/recvmsg.c
index 39de86f6..5e8b18c6 100644
--- a/sysdeps/mach/hurd/recvmsg.c
+++
Signed-off-by: Sergey Bugaev
---
And now it passes on x86_64-linux as well.
socket/Makefile | 1 +
socket/tst-cmsg_cloexec.c | 124 ++
2 files changed, 125 insertions(+)
create mode 100644 socket/tst-cmsg_cloexec.c
diff --git a/socket/Makefile
suite on i686-gnu, but
some manual testing confirms that the many superfluous term_getctty ()
RPC calls are gone, but the ctty functionality is still there, e.g. I
can fopen ("/dev/tty") and write to it and get the expected behavior.
This is different from my usual patches in that it mostly
* 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 ++--
csu/check_fds.c | 6 +++---
elf
commit will actually make use of O_IGNORE_CTTY
throughout the glibc codebase.
Signed-off-by: Sergey Bugaev
---
include/fcntl.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/fcntl.h b/include/fcntl.h
index be435047..3de40827 100644
--- a/include/fcntl.h
+++ b/include
This is nicer, and is going to be required for the following changes
to reasonably stay within the 79 column limit.
No functional change.
Signed-off-by: Sergey Bugaev
---
misc/daemon.c | 88 ---
1 file changed, 49 insertions(+), 39 deletions
the API defines whether or not the close-on-exec flag
shall be set on the returned fd).
Signed-off-by: Sergey Bugaev
---
catgets/open_catalog.c | 4 ++--
elf/dl-profile.c | 3 ++-
gmon/gmon.c| 7 ---
iconv/gconv_cache.c| 2 +-
login/utmp_file.c
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/dl-sysdep.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sysdeps/mach/hurd/dl-sysdep.c b/sysdeps/mach/hurd/dl-sysdep.c
index 2d595d00..6e167e12 100644
--- a/sysdeps/mach/hurd/dl-sysdep.c
+++ b/sysdeps/mach/hurd/dl
nto the slot.
Please try this:
Sergey
>8
>From 94fc9499390b4de9fbe10c3014d473ac42878c6a Mon Sep 17 00:00:00 2001
From: Sergey Bugaev
Date: Fri, 14 Apr 2023 16:32:45 +0300
Subject: [PATCH] hurd: Microoptimize sigreturn
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/i386/sigretur
This was always showing up as 0, because apparently we need to query
creation_time for the task, not a thread.
Here's a before vs after comparison:
$ cat /proc/self/stat ~/procfs/self/stat
11151 (cat) S 26571 11151 26571 0 0 0 0 0 0 0 1 0 0 0 20 0 2 0 0 154783744 251
0 134443008 134477480 0 0 0
This exposes msg_report_wait. For example:
$ msgport --report-wait --pid $$
26997: 2 threads
26997: thread 0: proc_wait_request [init#3]
26997: thread 1: msgport
---
utils/Makefile | 2 +-
utils/msgport.c | 74 +
2 files changed, 75 insertions(+),
Hello,
On Tue, Apr 18, 2023 at 3:13 PM Adhemerval Zanella Netto wrote:
> On 17/04/23 10:39, Sergey Bugaev via Libc-alpha wrote:
> > Signed-off-by: Sergey Bugaev
>
> Add some description of what the test is accomplishing here.
Do you mean in the commit message? Done.
Also change
; >
> >
> >
> > On 17/04/23 19:58, Sergey Bugaev via Libc-alpha wrote:
> > > This is nicer, and is going to be required for the following changes
> > > to reasonably stay within the 79 column limit.
> > >
> > > No functional ch
* 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 ++--
csu/check_fds.c | 6 +++---
elf
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/dl-sysdep.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sysdeps/mach/hurd/dl-sysdep.c b/sysdeps/mach/hurd/dl-sysdep.c
index 2d595d00..6e167e12 100644
--- a/sysdeps/mach/hurd/dl-sysdep.c
+++ b/sysdeps/mach/hurd/dl
This is nicer, and is going to be required for the following changes
to reasonably stay within the 79 column limit.
No functional change.
Signed-off-by: Sergey Bugaev
---
misc/daemon.c | 88 ---
1 file changed, 49 insertions(+), 39 deletions
s synchronous enough, and all
pending signals will get reliably delivered upon performing a syscall,
specifically setsid () in this case, so this change is still worth it.
Also, do not ignore erros from chdir ("/").
Suggested-by: Cristian Rodríguez
Signed-off-by: Sergey B
stdin is supposed to be readable, stdout and stderr writable. Otherwise,
we get this:
l-wx--. 1 root root 64 Apr 19 18:40 0 -> /dev/full
lr-x--. 1 root root 64 Apr 19 18:40 1 -> /dev/null
lr-x--. 1 root root 64 Apr 19 18:40 2 -> /dev/null
Signed-off-by: Sergey Bugaev
the API defines whether or not the close-on-exec flag
shall be set on the returned fd).
Reviewed-by: Adhemerval Zanella
Signed-off-by: Sergey Bugaev
---
catgets/open_catalog.c | 4 ++--
elf/dl-profile.c | 3 ++-
gmon/gmon.c| 7 ---
iconv/gconv_cache.c| 2
ing ctty RPCs in
all the other cases is still a solid improvement.
Sergey
Sergey Bugaev (7):
misc: Convert daemon () to GNU coding style
misc: Ignore SIGHUP in daemon () while forking
Use O_CLOEXEC in more places (BZ #15722)
csu: Fix standard fds' mode
hurd: Make dl-sysdep's o
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
On Wed, Apr 19, 2023, 22:13 Cristian Rodríguez wrote:
> Im a little bit lost on what it was supposed to do in this old form.. as the
> open flags are all wrong..
>
> Changelog says:
>
> (__libc_check_standard_fds): Reverse modes so that common operations on
> the descriptors fail.
>
> S
On Wed, Apr 19, 2023 at 10:48 PM Luca Dariz wrote:
> * i386/i386/pcb.c: switch FSBASE/GSBASE on context switch and
> implement accessors in thread setstatus/getstatus
> * i386/i386/thread.h: add new state to thread saved state
> * kern/thread.c: add i386_FSGS_BASE_STATE handler
Hi Luca -- this
On Wed, Apr 19, 2023 at 11:45 PM Adhemerval Zanella Netto
wrote:
> > I might be missing something, but why statically linked only? I don't
> > see anything like that in elf/Makefile (but maybe I don't know where
> > to look, please tell me!), and also the same behavior is certainly
> > exhibited b
On Wed, Apr 19, 2023 at 11:52 PM Sergey Bugaev wrote:
> On Wed, Apr 19, 2023 at 10:48 PM Luca Dariz wrote:
> > * i386/i386/pcb.c: switch FSBASE/GSBASE on context switch and
> > implement accessors in thread setstatus/getstatus
> > * i386/i386/thread.h: add new state
On Thu, Apr 20, 2023 at 2:56 PM Samuel Thibault wrote:
>
> Hello,
>
> Sergey Bugaev, le jeu. 20 avril 2023 14:51:04 +0300, a ecrit:
> > Why was this not an issue for us on i386?
>
> See 56010b73e81e2cb1082e418699f98353598fe671 and its __mig_memcpy.
Interesting; but tha
On Thu, Apr 20, 2023 at 3:08 PM Samuel Thibault wrote:
> > > See 56010b73e81e2cb1082e418699f98353598fe671 and its __mig_memcpy.
> >
> > Interesting; but that one's dealing with the SHARED case, isn't it?
>
> Yes but I guess it fixed the static case too?
We must be talking past each other -- evide
On Thu, Apr 20, 2023 at 3:33 PM Samuel Thibault wrote:
> Sergey Bugaev, le jeu. 20 avril 2023 15:27:15 +0300, a ecrit:
> > On Thu, Apr 20, 2023 at 3:08 PM Samuel Thibault
> > wrote:
> > > > > See 56010b73e81e2cb1082e418699f98353598fe671 and its __mig_memcpy.
&g
On Thu, Apr 20, 2023 at 4:01 PM Luca wrote:
> There is likely some limitation in the pmap module in gnumach, IIRC it should
> statically allocate the user L3 page tables as long as the limit is below the
> first 512GB, but I never really tested it yet.
That sounds plausible, yes, I've seen some
FWIW, mach-bootstrap-hello is supposed to then echo back what you type
on the console, but it doesn't work. From some debugging, it seems
that once I input something, the following device_write () call hangs
here:
(gdb)
ast_taken () at ../kern/ast.c:88
88 if (reasons & AST_NETWORK)
(gdb)
96 if (se
init1_desc assignment inside
_hurd_tls_init ().
Fixes cd019ddd892e182277fadd6aedccc57fa3923c8d
"hurd: Don't leak __hurd_reply_port0"
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/i386/tls.h | 18 --
sysdeps/mach/hurd/x86/init-first.c | 7 +--
sysde
e mig_strncpy.c), and is an ifunc-resolved function on both
x86_64 and i386.
Tested on x86_64-gnu (!).
Signed-off-by: Sergey Bugaev
---
Please tell me:
* if the approach is at all sane
* if there's a better way to do this without hardcoding
"__memcpy_sse2_unaligned"
* are the GOT
On Fri, Apr 21, 2023 at 12:14 AM Samuel Thibault
wrote:
> Sergey Bugaev, le lun. 17 avril 2023 16:38:59 +0300, a ecrit:
> > The only valid flag defined here is FD_CLOEXEC. It is of no concern to
> > the receiving process whether or not the sender process wants to close
> >
Hello,
On Fri, Apr 21, 2023 at 12:01 AM Samuel Thibault
wrote:
> BTW, which dynamic linker path do we have set for x86_64-gnu?
It's in gcc/config/i386/gnu64.h in GCC tree:
#define GNU_USER_DYNAMIC_LINKER64 "/lib/ld-x86-64.so.1"
It was added by Flavio.
So GCC passes -dynamic-linker /lib/ld-x86
Hello,
On Thu, Apr 20, 2023 at 11:38 PM Adhemerval Zanella Netto
wrote:
> Can't you use a similar strategy done by
> 5355f9ca7b10183ce06e8a18003ba30f43774858 ?
Do I understand it right that that is the moral equivalent of
#define memcpy __memcpy_sse2_unaligned
except that it works aat assembl
Hello,
On Thu, Apr 20, 2023 at 11:26 PM H.J. Lu wrote:
> Doesn't it disable IFUNC for memcpy and stpncpy?
I was hoping you'd tell me whether it does :|
I *think* on i386 it does indeed (so I'd need to rework that part of
the patch), but not on x86_64. This is based on the following
observations
On Fri, Apr 21, 2023 at 2:50 PM Adhemerval Zanella Netto
wrote:
> It might work if you don't care about a different architecture than x86,
> and that's why I added the alias (so each architecture is free to name
> its ifunc variant). And the patch was exactly to handle the implicit
> created mem*
On Fri, Apr 21, 2023 at 3:58 PM Adhemerval Zanella Netto
wrote:
> > Yes, sure, I wasn't really suggesting we do that change. My point is,
> > I would like to make the same memcpy callsites both work during early
> > startup and start calling the more efficient implementation once early
> > startup
On Fri, Apr 21, 2023 at 12:24 PM Samuel Thibault
wrote:
> No, they don't :) otherwise they wouldn't respect the ABI. The AMD64
> ABI indeed defaults to /lib/ld64.so.1, and says that Linux uses
> /lib64/ld-linux-x86-64.so.2, and that is cast in stone, we cannot change
> it any more.
>
> /lib/ld-x86
On Sat, Apr 22, 2023 at 2:17 PM Luca Dariz wrote:
> Hi Sergey,
Hi,
> Il 20/04/23 13:51, Sergey Bugaev ha scritto:
> > On Wed, Apr 19, 2023 at 11:52 PM Sergey Bugaev wrote:
> > We do reach the call to __thread_set_state (), but then it uses
> > __mig_memcpy (), whic
On Sat, Apr 22, 2023 at 2:59 PM Samuel Thibault wrote:
> Perhaps we can generate "init" variants of the RPCs that we need at
> initialization, that are made to use the base memcpy implementation, and
> only use them in the init code?
If we undo 56010b73e81e2cb1082e418699f98353598fe671 for static
On Sat, Apr 22, 2023 at 7:20 PM Samuel Thibault wrote:
> But what about the memcpy calls from the RPC stubs used by the init
> code?
Ah, I see that we do actually call more than I thought before _start1.
In particular, we initialize the dtable (so the ctty stuff...) and get
our pid/pgrp from the
dependent on the MSG_CMSG_CLOEXEC flag
being passed to the recvmsg () call, which is going to be implemented
in the following commit.
Fixes 344e755248ce02c0f8d095d11cc49e340703d926
"hurd: Support sending file descriptors over Unix sockets"
Signed-off-by: Sergey Bugaev
---
sysdeps
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/recv.c | 3 ++-
sysdeps/mach/hurd/recvfrom.c | 3 ++-
sysdeps/mach/hurd/recvmsg.c | 3 ++-
sysdeps/mach/hurd/sendmsg.c | 5 +++--
sysdeps/mach/hurd/sendto.c | 2 +-
5 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/sysdeps
MSG_CMSG_CLOEXEC to recvmsg ().
Checked on i686-gnu and x86_64-linux-gnu.
Reviewed-by: Adhemerval Zanella
Signed-off-by: Sergey Bugaev
---
socket/Makefile | 1 +
socket/tst-cmsg_cloexec.c | 126 ++
2 files changed, 127 insertions(+)
create mode 100644
another thread of the same process calling
(fork and then) exec at the same time.
This flag is already supported on Linux and FreeBSD. The flag's value,
0x4, is choosen to match FreeBSD's.
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/bits/socket.h | 5 -
sysdeps/mach/hurd
This makes the prefer_map_32bit_exec tunable no longer Linux-specific.
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/dl-sysdep.c | 5
sysdeps/mach/hurd/mmap.c | 6 +
sysdeps/unix/sysv/linux/x86_64/64/Makefile| 23
...in some more places.
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/dl-sysdep.c | 2 +-
sysdeps/mach/hurd/mmap.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/sysdeps/mach/hurd/dl-sysdep.c b/sysdeps/mach/hurd/dl-sysdep.c
index d7b309e0..25a12774 100644
D behavior.
Unlike on those systems, on the Hurd MAP_32BIT is defined on all
supported architectures (which currently are only i386 and x86_64).
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/bits/mman_ext.h | 1 +
sysdeps/mach/hurd/dl-sysdep.c | 8 +---
sysdeps/mach/hurd/mmap.c
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/mmap.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/sysdeps/mach/hurd/mmap.c b/sysdeps/mach/hurd/mmap.c
index 790eb238..d570be24 100644
--- a/sysdeps/mach/hurd/mmap.c
+++ b/sysdeps/mach/hurd/mmap.c
@@ -42,7 +42,8
and still want the attachment, let me know and we'll work
something out. And please ack receiving this one in any case.
---
On Sat, Apr 22, 2023 at 3:13 PM Samuel Thibault wrote:
>
> Sergey Bugaev, le sam. 22 avril 2023 15:11:30 +0300, a ecrit:
> > So please suggest your favorite
Hi,
On Mon, Apr 24, 2023 at 11:02 PM Luca Dariz wrote:
> Il 24/04/23 17:19, Sergey Bugaev ha scritto:
> > Resending without the attachment, because apparently the email did not
> > make it into the list archive so maybe it didn't get to you either;
> > and I'm
On Mon, Apr 24, 2023 at 11:47 PM Samuel Thibault
wrote:
> Is it really worth making the code a bit obscure?
No, not really.
What happened here was I looked at what my mask computation compiled
to, to verify it does the right thing on both x86_64 and i686, and
then I saw how the error branches ar
On Tue, Apr 25, 2023 at 12:02 AM Samuel Thibault
wrote:
> The two patches actually make me realize that there was a confusion here
> between FD_* flags and O_* flags. _hurd_intern_fd definitely takes O_*
> flags (and translates O_CLOEXEC to FD_CLOEXEC). If we are to transport
> some flags, it'd pr
On Tue, Apr 25, 2023 at 12:10 AM Samuel Thibault
wrote:
> Applied, thanks!
Thank you -- but I see you changed it to say "fds[j] | fd_flags".
For one thing it would be nice of you to indicate that this was your
change, not mine, because as things are it looks like I wrote that,
but I didn't. Linu
Hello,
I have done some debugging and I think I know what's going on, and it
looks related to this very patch. The device_read_inband () call
actually succeeds, and glibc tries to echo the same thing back (that's
how devstream works, arguably maybe it shouldn't, but whatever); and
when it tries to
On Tue, Apr 25, 2023 at 12:02 PM Sergey Bugaev wrote:
> subcode is the address of the fault, and 128 just so happens to be
> 0x80, and %fs:0x80 is of course tcb->reply_port. So it looks like
> fs_base was not restored to its proper value when context-switching to
> the thread, a
Hi Flavio,
could you please explain what the difference / the advantage of
new_dev_name_t is over dev_name_t? (Preferably, put it into the commit
message too.)
Isn't c_string same as MACH_MSG_TYPE_STRING_C? What are we gaining?
What is your overall plan concerning string handling in RPCs? The tw
Hi again,
I managed to break gnumach in a new and exciting way (tm):
../kern/ipc_tt.c:395: retrieve_task_self_fast: Assertion
`task->itk_self != IP_NULL' failed.panic ../kern/debug.c:103:
Debugger: Debugger invoked, but there isn't one!
This is after typing 'quit' in bc, which calls exit () -- I
On Fri, Apr 28, 2023 at 6:00 AM Flavio Cruz wrote:
> Dynamically sized strings can be represented as c_string[*] (*). We inline
> up to 64 bytes but can pass arbitrary strings if needed out of line. Currently
> implementation is limited to input arguments only (MiG will error out if
> used as outp
301 - 400 of 850 matches
Mail list logo
