|
From: Jeremy F. <je...@go...> - 2004-03-17 23:06:32
|
On Wed, 2004-03-17 at 08:28, Tom Hughes wrote:
> In message <107...@ix...>
> Jeremy Fitzhardinge <je...@go...> wrote:
>
> > On Tue, 2004-03-16 at 10:16, Tom Hughes wrote:
> >> I haven't done that for those ones because I'm still trying to make
> >> the sysinfo page solution that Jeremy suggested work, and that should
> >> remove those.
> >
> > Oh? What are you trying out?
>
> Well I was going to try and create a separate shared object that we
> could map into the sysinfo page, that way we could set the EHDR entry
> as well which should make glibc use the sysinfo page. I just haven't
> had time to try it yet...
I just got a chance to download and look at the glibc 2.3.3/FC2 sources,
which want to see the AT_SYSINFO_EHDR entry. It pretty clearly expects
to see a prelinked, premapped .so file containing the vsyscall
entrypoint. If we want to put this near the top of the client address
space, then we will need to be able to generate one of these with
different linked addresses, depending on where it has been placed. This
seems like too much hard work to me.
The other options I can see are:
1. just use the kernel provided EHDR, but copy it into the client
address space. When we see jumps to the kernel's sysinfo page
at 0xffffd000, use the EIP redirection to point it somewhere
more useful. I don't know what happens if we copy the EHDR to
another address without changing it though, but otherwise this
seems pretty simple.
2. Pick a low address (say, 64k), and put the sysinfo+sysinfo_ehdr
there. It will be fixed regardless of the client address space
configuration. The downside is that some programs may be linked
to go there, so we should place it only if there are no mappings
from the client executable there.
3. Special-case _dl_sysinfo_int80. Not too keen on this, but easy.
I might try hacking one of these up, unless you get to it first.
J
|