[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 5/5] add setting gs/fsbase

From: Sergey Bugaev
Subject: Re: [PATCH 5/5] add setting gs/fsbase
Date: Thu, 20 Apr 2023 15:46:51 +0300

On Thu, Apr 20, 2023 at 3:33 PM Samuel Thibault <samuel.thibault@gnu.org> 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 <samuel.thibault@gnu.org> 
> > 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?
> >
> > For the shared case, yes, lib*user will now reference
> > __mig_memcpy from libc.so, and that one needs a simple relocation
> > without ifunc.
> Ah, I missed the part that said that __mig_memcpy just calls the
> (ifunc-) memcpy.
> I guess I shouldn't be replying when I don't actually have time to check
> all ins and outs of what I'm talking about :)

It's alright, I'm guilty of that too :) And also indeed I have just
spent hours debugging this, so I have some mental model of what's
going on (whether a correct one is another question...), but if you
haven't looked into this for some time, you wouldn't.

> > What would be a correct value then, 1 << 48?
> I don't know by heart, but something like that yes.

Well that value is making gnumach crash before the task even runs :(

XNU has 0x7ffffffff000, which is still larger than 0x200000000000, so
I'm going to try that one. Though they probably mean 0x800000000000
and have just left a single page of address space for the commpage.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]