|
From: Tom H. <th...@cy...> - 2004-07-11 11:11:47
|
In message <1089150608.3089.1.camel@localhost>
Jeremy Fitzhardinge <je...@go...> wrote:
> On Mon, 2004-07-05 at 08:47 +0100, Tom Hughes wrote:
> > I agree that it's pretty braindead. In fact older versions of libaio
> > don't seem to peek at the memory in this way, but the fact that it is
> > mapped in user space suggests that it was always intended.
>
> Well, I think the practical solution is to do what we do to convince ld.
> so to put things in the right place: pad the Valgrind portion of the
> address space before the io_setup, and remove the padding afterwards.
> That will force io_setup to allocate its mapping in the client address
> space.
I've been working on this, and it's certainly fun...
The first problem I ran into was that the space from valgrind_mmap_end
to valgrind_end is all in the segment list regardless of whether or not
it has anything mapped at the kernel level. I think this is to stop
valgrind using it for memory mapping.
I can work around that by marking the segments which are not mapped so
that I know I need to pad them, but it turns out the VG_(brk) doesn't
update the segment list which it gives out memory and I've far been
unable to make it do so as it just seems to either segfault or get into
an infinite loop.
I've cludged around that for now, but now I find that the kernel is
choosing to allocate the io_setup page at the top of the client address
space, immediately below the client stack, thus stopping it from being
extended!
So it looks like I will have to pad the client address space as well
in order to control where the kernel puts that page...
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|