We still need to modify the syntactic analysis to build regions for dynamically allocated memory but yeah, that’s the idea. A points-to analysis will implement them accurately.

Greg Bronevetsky
Lawrence Livermore National Lab
(925) 424-5756
bronevetsky@llnl.gov<mailto:bronevetsky@llnl.gov>
http://greg.bronevetsky.com

From: Sriram Aananthakrishnan [mailto:notifications@github.com]
Sent: Monday, November 04, 2013 3:57 PM
To: sriram87/edg4x-rose
Cc: bronevet
Subject: Re: [edg4x-rose] Fuse dev integration 11/3/13 (#1)


In projects/fuse/src/analysis/abstract_object.h:

> -  // Useful since AbstractObjects can change from one Part to another.

> -  virtual std::string strp(PartEdgePtr pedge, std::string indent="")

> -  { return str(indent); }

> -};

> +/* ###########################

> +   ##### MemRegionObject #####

> +   ###########################

> +

> +Denote sets of contiguous memory regions. In the memory model of C/C++ and most other languages

> +memory is divided into disjoint contiguous regions of memory with no constraints on their

> +adresses. For instance, two malloc-ed buffers are guaranteed to be disjoint but may be placed

> +anywhere in memory. The same is true for the memory regions that hold different function local

> +variables. Although their lifetime is defined, their absolute or relative memory locations are not.

> +Memory regions denote such buffers, providing a way to distinguish them from each other and

> +identify their sizes but not learn any additional information about their locations.

> +*/

Cool. This allows us to model arrays and heaps. But when do you build these regions for malloc/new ? Or in general everything is a region and its size it initialized by some analysis when it sees new/malloc?

—
Reply to this email directly or view it on GitHub<https://github.com/sriram87/edg4x-rose/pull/1/files#r7418210>.