Re: [Valgrind-developers] recent new Auxv on Linux

[Tom H. <to...@co...>]

On 04/09/09 04:26, John Reiser wrote:
> On 09/03/2009 03:04 PM, Tom Hughes wrote:
>> On 03/09/09 21:53, John Reiser wrote:
>>
>>> Also, the page referenced by AT_SYSINFO (and/or AT_SYSINFO_EHDR) should
>>> be forcefully discarded if possible. Otherwise it may get in the way
>>> of mmap() by user and/or coregrind. This is particularly troublesome
>>> when the placement of the VDSO is randomized, such as the Fedora distro.
>>> Can we get a VG_(munmap) ?
>>
>> I've got a patch to do that that I've been using to help with wine
>> support and I've been meaning to see about getting it committed...
>
> Hmmmm... What does the patch do regarding coordinating the view
> of the layout of the address space between wine-preloader and
> valgrind's address space manager? Is there a svn branch where
> this work can be seen?

Well I actually have two patches to make wine+valgrind work on Fedora at 
the moment.

The first (which is attached) is the one I was talking about which 
unmaps the vdso to get it out of the way. Given that we already hide the 
vdso from the client anyway this should be entirely harmless and unless 
anybody objects I will commit it shortly.

The second tweaks the load addresses in configure and tweaks 
aspacem_minAddr in the address space manager to make valgrind appear at 
a relatively high address and hence stay out of the way of wine.

>> The only possible problem is that there is now a system call that is
>> only implemented as a vsyscall which may make discarding the vdso page a
>> problem. Not that the system call in question work under valgrind at the
>> moment anyway (there is a bug for that).
>
> Yes, Fedora's randomization of placement of vdso will have to be
> constrained. I generated a patch to Fedora's kernel a couple years ago,
> but it didn't "stick." The patch offered a choice: no vdso, vdso at
> random empty page [the only choice today], vdso just below STACK_TOP,
> vdso just below main .text, vdso just below PT_INTERP.

I think I actually got a bit confused - there are two different things 
which (oddly) seem to do the same thing. The vdso (which we hide by 
masking it out of auxv) and the vsyscall area which is at a fixed high 
address - it is the latter that bug #187043 refers to where we do not 
trap the calls to the sched_getcpu routine in the vsyscall page.

Tom

-- 
Tom Hughes (to...@co...)
http://www.compton.nu/