[cfe-dev] Converting pointers to fat pointers

[John Criswell]

On 5/14/12 9:57 PM, Sai Charan wrote:
> In the interest of time & effort, I am leaning on working at the LLVM 
> IR level.
>
> 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.

Ignoring intrinsic functions, the only LLVM IR instructions that 
dereference pointers are load and store.

The intrinsics that access memory via pointers should be pretty easy to 
spot when you read through the LLVM Language Reference Manual: things 
like the atomic intrinsics, the string manipulating intrinsics, etc.

You can see what SAFECode does by looking at the LoadStoreChecks.cpp 
source code.  You can probably find the equivalent code in the SoftBound 
code, but I do not know myself where it is.

-- John T.


>
> Sai Charan,
> CSE, UC Riverside.
>
>
>
> On Mon, May 14, 2012 at 7:23 PM, John Criswell <criswell at illinois.edu 
> <mailto: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 list
>>     cfe-dev at cs.uiuc.edu  <mailto:cfe-dev at cs.uiuc.edu>
>>     http://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/7abb5ee1/attachment.html>