|
From: Julian S. <js...@ac...> - 2005-05-03 17:44:48
|
All, As a result of recent memcheck hackery in the 3.0 line, I broke support for the VALGRIND_SET_VBITS and VALGRIND_GET_VBITS client requests. I haven't fixed them; instead I am hoping to get rid of them altogether. They were introduced as an experimental hack, and as far as I know nobody ever used them. So my question is: does anybody use these? If you haven't a clue what this is about, it's a pretty safe bet you don't use them. J |
|
From: Jeremy F. <je...@go...> - 2005-05-09 21:11:52
|
Julian Seward wrote:
>All,
>
>As a result of recent memcheck hackery in the 3.0 line, I broke
>support for the VALGRIND_SET_VBITS and VALGRIND_GET_VBITS
>client requests. I haven't fixed them; instead I am hoping to
>get rid of them altogether. They were introduced as an experimental
>hack, and as far as I know nobody ever used them.
>
>So my question is: does anybody use these?
>
I think there are lots of potential for clustered Valgrind, but they
should be relatively easy to put back if/when the time comes.
J
|
|
From: Oleksandr K. <ti...@gm...> - 2006-07-07 10:45:07
|
Julian Seward <jseward <at> acm.org> writes: > > > All, > > As a result of recent memcheck hackery in the 3.0 line, I broke > support for the VALGRIND_SET_VBITS and VALGRIND_GET_VBITS > client requests. I haven't fixed them; instead I am hoping to > get rid of them altogether. They were introduced as an experimental > hack, and as far as I know nobody ever used them. > > So my question is: does anybody use these? > > If you haven't a clue what this is about, it's a pretty safe bet > you don't use them. > Hi, I do need the GET/SET VBITS requests! The case is when one implements virtual memory-like system in which memory contents may be offloaded from RAM even if memory page's contents is only partially defined (and the page is dirty already). It is actually for "memory buffer" of a database management system (for non- standard embedded environment). All data is processed in one region of memory where memory pages loaded and offloaded from/to disk. The pattern to use is: GET_VBITS(...); // save vbits state MAKE_READABLE(page, page_size); // prevent complaints when page data is writen to file MemoryBuffer::SavePage(page, ..); // save(flush) page - it stays in memory SET_VBITS(...); // restore It becomes even worse, if there is a need to preserve VBITS for completely offloaded pages. Then, in debug builds VBITS must be stored along with memory pages' data in file system and restored when page is brought back into the memory buffer! - Oleksandr |
|
From: Patrick O. <pat...@in...> - 2006-07-07 12:10:54
|
On Fri, 2006-07-07 at 10:41 +0000, Oleksandr K. wrote: > Julian Seward <jseward <at> acm.org> writes: > > As a result of recent memcheck hackery in the 3.0 line, I broke > > support for the VALGRIND_SET_VBITS and VALGRIND_GET_VBITS > > client requests. I haven't fixed them; instead I am hoping to > > get rid of them altogether. They were introduced as an experimental > > hack, and as far as I know nobody ever used them. > > > > So my question is: does anybody use these? > > > > If you haven't a clue what this is about, it's a pretty safe bet > > you don't use them. > > > > Hi, > > I do need the GET/SET VBITS requests! They are supported again since at least 3.2.0. Just beware that the client request mechanism has changed and therefore you have to use the header files from that valgrind version to use the new requests. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. |