|
From: John R. <jr...@bi...> - 2009-09-03 20:53:52
Attachments:
recent-auxv-linux.patch
|
Hi,
There have been new AT_* tags for Linux in the past year or so:
AT_BASE_PLATFORM: the real hardware platform [compare AT_PLATFORM:
the virtual hardware platform]
AT_EXECFN: the filename at execve(); like readlink("/proc/self/exe",)
but Linux will never erase the string [the link for /proc/self/exe
can disappear in some cases]
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) ?
--
|
|
From: Tom H. <to...@co...> - 2009-09-03 22:04:09
|
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... My approach was to use VG_(am_find_nsegment) and then discard the whole segment with VG_(am_munmap_valgrind) as the auxv doesn't give any clue to the size of the mapping. 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). Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: John R. <jr...@bi...> - 2009-09-04 03:26:35
|
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? > My approach was to use VG_(am_find_nsegment) and then discard the whole > segment with VG_(am_munmap_valgrind) as the auxv doesn't give any clue > to the size of the mapping. > > 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. -- |
|
From: Tom H. <to...@co...> - 2009-09-04 14:37:40
Attachments:
valgrind-vdso.patch
|
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/ |
|
From: John R. <jr...@bi...> - 2009-09-04 17:01:08
|
On 09/04/2009 06:30 AM, Tom Hughes wrote:
> The second [patch] 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.
Yes, putting valgrind and tools up above 0x68000000, and not in
[0x7f000000, 0x82000000), is a good idea. I prefer 0x78000000 on i686,
and 0xec000000 for i686 under x86_64. That's what I use now.
I want to be more aggressive about connecting the Win32 address space
reservations in Wine to valgrind's address space manager.
Consider the flow of execve() when a user wants to memcheck a Wine app
such as Notepad.
1) shell invokes
sys_execve valgrind args-for-valgrind wine Notepad
2) valgrind invokes
sys_execve memcheck args-for-valgrind wine Notepad
3) memcheck supervises
wine Notepad
4) wine-under-memcheck sets environment variable WINELOADERNOEXEC=1
(to prevent its own internal recursion), then invokes
sys_execve wine-preloader wine Notepad
PRE(sys_execve) used to turn this into
sys_execve valgrind args-for-valgrind wine-prelodaer wine Notepad
which would then result in
sys_execve memcheck args-for-valgrind wine-preloader wine Notepad
Instead, PRE(sys_execve) should detect "wine-preloader" [by command-line option
such as "--preloader=wine-preloader"], and rotate the arguments to become
sys_execve wine-preloader memcheck args-for-valgrind wine Notepad
5) wine-preloader reserves address space, then does
user_execve memcheck args-for-valgrind wine Notepad
where user_execve is a direct user-mode mmap+jump instead of a kernel execve.
6) memcheck discovers the reservations through /proc/self/maps (and/or reads
wine_main_preload_info[] (and/or AT_WINE_PRELOAD_INFO) and verifies it),
then supervises
wine Notepad
The "memcheck" arg in steps 4) and 5) must be the complete tool name
including path prefix. This can be remembered in a global variable from
memcheck's own argv[0], or obtained from /proc/self/exe, or from AT_EXECFN.
The key step is 4), where PRE(sys_execve) changes from
sys_execve valgrind args-for-valgrind wine-prelodaer wine Notepad
to
sys_execve wine-preloader memcheck args-for-valgrind wine Notepad
Two vital changes are required. wine-preloader should be handled
specially because it invokes user_execve instead of sys_execve. The sys_execve
from valgrind to memcheck should be elided in order for wine-preloader
to invoke memcheck with the address-space reservations already in effect.
There is one side effect: wine-preloader is not memcheck'ed. The benefit
is a direct handoff of address space reservations from wine-preloader
to memcheck for the memcheck-supervised execution of "wine Notepad".
--
|