|
From: Tom H. <to...@co...> - 2005-09-20 07:55:26
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> * Tom: you had some layout issues re amd64? Can you outline them
> again? You said you had to change map_base in order that the
> dataseg placement didn't fail. I need to make the dataseg
> placement more robust.
You seem to have addressed most of these last night, although in
different ways to me.
There are (or were) two show stoppers. The first was the fact that
memory below the 64Mb point was reserved which I fixed by only
reserving 4Mb and you have now fixed by allowing fixed maps in
reserved areas.
The second was that the interpreter tended to get mapped immediately
above the client which then caused mapping of the data segment to
fail. I fixed that by moving map_base and you fixed it by moving the
data segment if the first mapping failed. My patch to map the
interpreter at it's preferred address can also help with this by
stopping it being mapped immediately above the client so I have
just committed that - it is good anyway as it makes the memory layout
more like the non-valgrind case.
One outstanding patch I have which I mentioned before it to adjust
the memory layout a bit so valgrind's allocations are properly above
the 16Gb level and the client stack is below it. That patch is
attached - it also reduces the reserved chunk at address zero
to 4Mb but you might want to drop that bit now.
The major outstanding problem I'm seeing on x86 is the redirection
of _dl_sysinfo_int80 to a routine inside valgrind as valgrind now
refuses to do a translation from code in an SkFileV segment. There
is a similar problem with the vsyscall routines on amd64.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|