Identifying functions writing to memory at LLVM-IR level

Dear All,

I am new to LLVM and using it create a simple pass for array bounds checking.

How can i retrieve pointer to a memory area that is accessed by a function call . I have written a Pass that can intercept function calls and detect whether it is writing to a memory on not using Instruction::mayWriteToMemory(). Whether a function accessing memory or not can be checked by Instruction::mayReadFromMemory() and Instruction::mayWriteToMemory() but how can i get staring address of those memory areas (program variables) that are being written by.

For example, for the c code

int main(){

char arrd[]="This is destination ";

char arrs[]=“COPIED STRING”;

strcpy(arrd, arrs);

printf(“Final copied string : %s\n”, arrd);

return 0;


Does LLVM at IR level provide such functionality to intercept call to “strcpy” and provide starting and end address of any data variables being written by it?


Ahmed Saeed,

Research Student,

Glasgow Caledonian University, UK.

Are you performing static array bounds checking within the compiler, or are you adding code to the program to check array bounds when the program is executed? For static array bounds checking, you’ll need to use a points-to analysis (e.g., DSA from the poolalloc project) to get an approximation of the memory objects accessed by a pointer. For dynamic array bounds checking, you’ll need to instrument the program so that the bounds of all memory objects are recorded in side data structures and then add code before strcpy() to find the bounds information associated with a given pointer using those side data structures. The SAFECode compiler () instruments code to do dynamic array bounds checking. If you want to check for dynamic array bounds violations, SAFECode already does that (as does SoftBound, which is included in the SAFECode source code). Address Sanitizer pretty much does this, too, although its design can permit out-of-bounds array indexing violations if the pointer arithmetic uses very large strides. Regards, John Criswell