Hello,
I faced a small problem at the end of GSoC. The problem was that the patch
set faced "dirty patch" warnings while applying them on a fresh Valgrind
source.
So I looked up about it and came to the conclusion that they couldn't be
solved easily. There were alternatives like forking(or import
Richard Braun, le Sat 13 Sep 2014 10:13:48 +0200, a écrit :
> (with the interesting addition that, if MAP_FIXED isn't set,
> but the hint is non-zero, the returned mapping must not start at
> address 0).
Well, it's not easy to implement this, since vm_map is generic, and
could be used for other ki
On Sat, Sep 13, 2014 at 01:39:05AM +0200, Samuel Thibault wrote:
> So it seems we need what is not actually documented, i.e. a vm_map
> with anywhere=1, but which takes into account the suggested address.
> I'm fine with officially supporting that, we just need to fix the
> documentation, and fix a
Samuel Thibault, le Sat 13 Sep 2014 09:54:56 +0200, a écrit :
> I've dug a bit more, glibc's _hurd_startup reserves page 0, so no vm_map
> or vm_allocate call should be allocating at address 0. But with the
> change, address 0 is already taken by the first mapped binary, ld.so. I
> guess exec needs
Justus Winter, le Sat 13 Sep 2014 02:40:17 +0200, a écrit :
> Quoting Samuel Thibault (2014-09-13 01:39:05)
> > So it seems we need what is not actually documented, i.e. a vm_map
> > with anywhere=1, but which takes into account the suggested address.
> > I'm fine with officially supporting that, w
