|
From: Julian S. <js...@ac...> - 2005-02-14 11:54:36
|
> 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? Well, only on code which is compiled using this "small model" (or whatever it's really called). That can still be 64-bit code; the critical thing is the assumptions made by the compiler+binutils about whether all inter-code offsets can fit in a 32-bit signed integer, or not. At least, this is my understanding of it. 2G, 4G, I'm not sure which. Either way, same principle. > 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. That is true. Well, we could optionally leave pointercheck enabled even with Memcheck if people wanted this. Frankly I'm unsympathetic to the view that even after a program does a bad write which is reported by Memcheck, it should not actually trash Valgrind. My view is, once a bad write is reported, you can just forget the rest of your run on the basis that V _might_ have gotten trashed. I said as much in the valgrind-1.0 release notes, and I can't remember getting complaints about this behaviour. > > 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. Duh, sorry, yes, forgot to mention that. J |