|
From: Tom H. <to...@co...> - 2005-02-14 11:39:28
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> On amd64 that scheme isn't going to work, since all
> client code has to be below 2G. A more flexible layout is
> needed.
Only for 32 bit client programs presumably. Even then the limit
is 4G surely?
> One observation is (unless I am wrong) is that pointercheck
> is valueless when running Memcheck, since Memcheck should be
> able to catch all illegal accesses (if this isn't true then
> Memcheck is broken and we should fix it). That means we
> can omit pointercheck when doing Memcheck and so any
> software-based checking scheme will have zero overhead for
> our most-used tool.
The advantage of pointercheck when memcheck is used is that although
memcheck may spot a write to valgrind's memory and complain about it
the write will still go ahead and corrupt valgrind's data structures
leading to an obscure crash later on.
With pointercheck the process is aborted immediately with a clear
message that the client tried to mess with valgrind.
> Access checks are performed using a table of booleans (bytes),
> one for each superblock in the address space (with some qualification
> for 64-bit address spaces, see below). The checking code can easily
> enough be expressed in Vex's IR and turned into efficient machine
> code by Vex's back ends, so there is no portability issue there.
>
> A check is a basically
>
> if (table[address >> n])
> goto invalid-access
Presumably the idea is that valgrind blocks will be marked as
inaccessible in that table so that attempts by the client to access
them in any way would fail, thus preserving the current pointercheck
behaviour.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|