|
From: Doug R. <df...@nl...> - 2004-03-02 23:09:10
|
On Tue, 2004-03-02 at 22:08, Jeremy Fitzhardinge wrote: > On Tue, 2004-03-02 at 01:14, Doug Rabson wrote: > > I had another problem yesterday where layout_remaining_space was failing > > to mmap the redzone and the shadow map. I added yet another flag to > > VG_(mmap) to allow mapping the shadow area but it all starts to feel > > wrong. The other idea I had yesterday was to add a new flag, e.g. > > VKI_MAP_NOCHECKING. The mmap override would or this in to the flags > > passed to VG_(mmap) and that would turn off the client/valgrind address > > space checks. This would leave ume.c just using the plain standard mmap > > api. > > Hm, yes. For the sake of correctness, I think it is a good idea if > we're clear about the intent of each mmap(), and whether it should be > allowed to go into the client address space or not. If we're using > !MAP_FIXED, then it's obviously critical that it explicitly says which > address space it should go into. > > I was playing with having two flags rather than just one: > VKI_MAP_CLIENT, and VKI_MAP_VALGRIND (ie, all address space except the > client). This would allow us to say VG_(mmap)(..., > VKI_MAP_*|VKI_MAP_FIXED|VKI_MAP_CLIENT|VKI_MAP_VALGRIND,...), meaning > that we're OK with the mapping going into either address space, for the > use of ume.c. (We could make ume.c always use VG_(mmap) rather than > mmap, and provide an appropriate implementation for use in stage1.) I'm already doing something like this but I have problems with the bits of vg_main.c which map red-zones and the shadow area since the checking in VG_(mmap) is quite strict. |