bug-hurd
[Top][All Lists]
Advanced

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

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


From: Samuel Thibault
Subject: Re: [PATCH 5/5] add setting gs/fsbase
Date: Thu, 20 Apr 2023 14:33:10 +0200
User-agent: NeoMutt/20170609 (1.8.3)

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

> > > > > VM_MAX_USER_ADDRESS, which is defined to VM_MAX_ADDRESS, which is then
> > > > > defined to 0xc0000000, same as on i386. That's of course too small.
> > > > > Can we bump this substantially?
> > > >
> > > > Of course !
> > >
> > > Let me actually try doing #define VM_MAX_ADDRESS KENEL_MAP_BASE...
> >
> > It doesn't need to be that high :)
> >
> > And actually it probably cannot: IIRC not all bits can be used in amd64
> > virtual addresses anyway.
> 
> Yes, but apparently it still works for the kernel? Or is that some
> other kind of address?

IIRC the last really-usable bit of the virtual address is just
replicated (to 0 for user and to 1 for kernel).

> What would be a correct value then, 1 << 48?

I don't know by heart, but something like that yes.

Samuel



reply via email to

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