[cfe-dev] Converting pointers to fat pointers

Sai Charan scharan at cs.ucr.edu
Mon May 14 19:57:26 PDT 2012

In the interest of time & effort, I am leaning on working at the LLVM IR

The code listing in section 3.1 of the SoftBound paper is precisely what I
am looking to do. However, the listing is at the C source level, while
section 6 says that the implementation has been done on the LLVM IR; I
don't see how I can figure out pointer de-references in LLVM IR. Every
alloca/load/store is via <ty>*.

In summary, how do I figure out pointer de-references in LLVM IR.

Sai Charan,
CSE, UC Riverside.

On Mon, May 14, 2012 at 7:23 PM, John Criswell <criswell at illinois.edu>wrote:

>  On 5/14/12 8:11 PM, John McCall wrote:
>  On May 14, 2012, at 5:59 PM, Sai Charan wrote:
> I am looking at using LLVM/Clang to automatically convert pointer
> declarations to fat pointers & the corresponding dereferences to something
> appropriate. I am looking for guidance on doing this. Will an LLVM pass be
> better suited to this or would this be better handled using Clang. Any
> guidance on getting started would be helpful.
>  It would be best handled by modifying Clang, both in semantic analysis
> (to change the size of a pointer) and IR generation (to generate,
> propagate, and consume your fat pointer values).  I'm afraid that clang's
> IR generation widely assumes that pointers are represented as a single
> llvm::Value, though, and you might be in for a lot of work.
> Converting to fat pointers can also be done at the LLVM IR level and, in
> fact, there's a modern implementation of fat pointers at the LLVM IR level
> in the SAFECode project (http://sva.cs.illinois.edu).  The implementation
> is SoftBound from University of Pennsylvania, and it implements what is
> essentially a fat pointer approach that does not modify data structure
> layout.  You can read about SoftBound at
> http://www.cis.upenn.edu/acg/papers/pldi09_softbound.pdf.
> One of the problems with implementing fat pointers within clang is that
> clang does not have the entire program, and so you cannot use whole program
> analysis to determine if parts of the program are aware of the data
> structure layout.  An LLVM IR analysis that is part of the link-time
> optimization framework can, and so a transform at the LLVM IR level could
> determine when it is safe to modify a data structure layout and when it is
> not.
> All that said, if you're using a fat pointer method that doesn't modify
> data structure layout (SoftBound has this feature; Xu et. al.'s work at
> http://seclab.cs.sunysb.edu/seclab/pubs/fse04.pdf doesn't either, IIRC),
> implementing it in Clang would also work.
> As an FYI, I'm advocating for a common infrastructure in LLVM for adding
> and optimizing memory safety run-time checks; the idea is to have common
> infrastructure that will work both for fat pointer approaches, object
> metadata approaches, and other approaches.  You can find my proposal at
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120507/142532.html.
> I'd welcome any feedback or comments you may have on it.
> -- John T.
>  John.
> _______________________________________________
> cfe-dev mailing listcfe-dev at cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120514/c3ec4084/attachment.html>

More information about the cfe-dev mailing list