How to get the runtime memory region information when instrumenting using Pin?

Question

I am using Pin for some execution monitoring tasks towards x64 ELF binary code.

During the monitoring, for any memory write/read operation of the original code, I would like to record it as long as it refers the heap. However, given a memory address, I have no idea whether it refers the heap memory region or not.

One possible solution I can come up with is that, before every memory operation, I acquire the runtime memory region information of the target process, and check whether the current memory address is within the heap region. This can be done by following the steps below inside the Pintool.

1. acquire the process ID of monitored process (This step can use Pin API Pin_GetPid)
2. read the process memory region information in /proc/XXX/maps
3. find the heap memory region
4. check whether the current address is within the heap region

However, this is tedious and my test shows that this is extremely slow, as the size of memory heap can change during the runtime which means I need to go through the above steps everytime before memory operation.

So I am wondering, does Pin has APIs to provide the heap memory region information? Or is there any solution more efficient that the above one?

===================== update ===============================

Answer 1

As you're saying you're using ELF code, i assume you're running under Linux, or another unix-y system. And proc/self/maps (you don't have to getpid() and use /proc/XXX/maps, really) hints at Linux as well.

One problem i see is the definition of heap - what about memory mapped regions, do they count as "heap" or not? Linux malloc uses mmap in some cases instead of expanding the heap, which is typically done by brk (which may itself be just a wrapper around mmap/mremap depending on your libc).

If you want to trace everything that's in malloced memory, i'd just compare the address to the end of the code segment (but beware of dynamic libraries; or omit that comparison completely as code typically isn't read and can't be written anyway) and the current value of the stack pointer. If the address is below the stack pointer, assume heap.

If you want to trace what's in the original, brk-managed heap only, read your memory map just once at the start, getting the heap start address, and monitor brk calls, adjusting the end address after each brk.

On x64, "below the stack pointer" must be taken with a grain of salt. On 16- and 32-bit x86 processors, anything below the stack pointer can be clobbered by hardware interrupts at any time, so sp/esp are a barrier to what software can use. On 64 bit processors, however, the ABI guarantees that 128 bytes below the stack pointer aren't changed by interrupts, so the compiler is free to use them (and will do so in leaf functions). Which means, you really need to compare your address to esp-0x80 if you're dealing with x64 code.