|
From: Oliver S. <ol...@f-...> - 2010-02-17 13:28:47
|
Hi, several systems use tagged memory to identify blocks of memory used by the same code and similar. What would be the best way of telling Valgrind about this custom allocation scheme? The "Memory Pools" don't seem to cover the possibility of tagged memory, as they only take parameters similar to malloc() itself. Tagged memory comes in several flavors and in some cases it is important to pass the same tag to the counterpart of the allocation function as was given at the time of allocation. Therefore dropping the tag isn't an option either. Thanks in advance, // Oliver |
|
From: Kaz K. <kky...@gm...> - 2010-02-18 20:45:49
|
On Wed, Feb 17, 2010 at 5:28 AM, Oliver Schneider <ol...@f-...> wrote: > Hi, > > several systems use tagged memory to identify blocks of memory used by > the same code and similar. What would be the best way of telling > Valgrind about this custom allocation scheme? What is the goal in integrating Valgrind with this scheme; that is, what is not happening now which should be? > Tagged memory comes in several flavors and in some cases it is important > to pass the same tag to the counterpart of the allocation function as > was given at the time of allocation. How is the tagged memory allocator obtaining the memory? Is it not bootstrapped from some lower-level allocator which doesn't know about the tags? You can write higher level allocators which add additional meta-data to memory blocks, such that the application cannot read or write the meta-data (and thus accidentally overwrite it without detection). The way to do this is to simply mark the meta-data unreadable before returning the block of memory to the application, and only opening/closing access to that meta-data when manipulating it inside the allocator, using the VALGRIND_MAKE_MEM_DEFINED and VALGRIND_MAKE_MEM_NOACCESS macros. Fresh, uninitialized storage returned to the program (which the program can write, but should not read) is set up using VALGRIND_MAKE_MEM_UNDEFINED. |
|
From: Oliver S. <ol...@f-...> - 2010-02-18 22:14:35
|
Hello and thanks first of all for your detailed reply. > What is the goal in integrating Valgrind with this scheme; that is, > what is not happening now which should be? For example checking whether the allocation function and its counter-part use the same tag. I thought it would be better to integrate it into an existing solution rather than writing my own that would then also point out call-stacks for the allocation code path. > How is the tagged memory allocator obtaining the memory? > Is it not bootstrapped from some lower-level allocator which doesn't > know about the tags? Yes, ultimately from malloc. So I'm looking for a way to replace it, really. > The way to do this is to simply mark the meta-data unreadable > before returning the block of memory to the application, and > only opening/closing access to that meta-data when manipulating > it inside the allocator, using the VALGRIND_MAKE_MEM_DEFINED > and VALGRIND_MAKE_MEM_NOACCESS macros. > Fresh, uninitialized storage returned to the program (which the > program can write, but should not read) is set up using > VALGRIND_MAKE_MEM_UNDEFINED. Great, this is exactly the information I was looking for from looking at the headers and the manual. Thanks a lot, // Oliver |