[PATCH] Intercept allocation to skim allocated types

[Douglas Gregor]

On Feb 4, 2013, at 9:18 AM, Dai MIKURUBE <dmikurube at acm.org> wrote:

> Thank you, Douglas and John,
> 
> The idea "somehow" sounds good and reasonable to me, so I'm basically positive to try and implement it.  But sorry, I'm still not sure of what it actually does...
> 
> In this idea, the operator new is replaced.  So,
> 1) Who finally calls the original operator new? (User's replacement operator new does?)

Yes.

> 2) Who "associates" the type of a particular "new" expression with the address?

The replacement new would sniff out its return address.

> 3) Who "records" the association, and where is it recorded?

The compiler records it, probably in the DWARF. DWARF exceptions work this way, with a side table mapping instruction address ranges to EH information.

	- Doug

> 
> 2013/2/1 John McCall <rjmccall at apple.com>
> On Jan 31, 2013, at 10:53 AM, Douglas Gregor <dgregor at apple.com> wrote:
> > On Jan 31, 2013, at 9:22 AM, Dai MIKURUBE <dmikurube at acm.org> wrote:
> >> Thank you for the comments, John and Richard.
> >>
> >> At first, I don't stick to this design and implementation (I'm saying not to make misunderstanding).  I'd just like to solve the following problem.
> >>
> >> 1) Capture allocated types of as most objects as possible.
> >> 2) No need to change almost all the existing code.  Just adding some code.
> >> 3) Capture objects allocated by both global and in-class operator new.  (Many projects naturally have many in-class operator new.)
> >> 4) Capture objects allocated by placement new.  (Placement new is used for malloc() memory allocation in some projects.)
> >> 5) Actually, capturing object deallocation is less required for our purpose.  (But, it's more required in general.)
> >>
> >> If we can solve this problem in another better way, I'm so positive to switch to the way.  Do you have any ideas?  It's useless without (3) and (4) as I discussed in the previous comment and the document.
> >>
> >
> > John has sketched out of potential scheme:
> >
> >       Perhaps it would be better to replace operator new, record return addresses, and then somehow map those back to source code?
> >
> > Basically, the idea here is to associate the type of a particular "new" expression with the address at which the call to operator new occurs (DWARF does this sort of thing), so when we're emitting IR for
> >
> >       new A
> >
> > the type of A is associated with the address of the associated call instruction.
> >
> > Then, you replace operator new with whatever function interposition approach is right for your platform (LD_PRELOAD, DYLD_INSERT_LIBRARIES, whatever). The replacement operator new sniffs out its return address, then matches that up with the corresponding call site to get type information. If it can't find the type information (because the call site wasn't compiled with it), at least you're still catching the allocation.
> >
> > There are several advantages to John's suggestion over your current approach. For one, it requires no changes to semantic analysis or the AST, so turning this feature on isn't going to change the meaning of your source code, and the implementation can be limited to Clang's lowering + some work on the LLVM side. Second, the type information can be recorded off to the side (e.g., like DWARF exception tables), so they don't have an impact on how the code executes. Because of this and the fact that one can interpose operator new/operator delete at run time, it means that one could emit this information as part of the build and then decide at run time whether to interpose or not, so it becomes just another debugging/profiling aid that one could generate with the rest of the debug info.
> 
> Right, and it's relatively straightforward to sniff out non-global operator news (by mangled symbol name) and interpose them all.
> 
> This approach would *not* work when operator new is potentially optimized out, e.g. when it's inlined, as is the case with the global placement new.
> 
> Yes, this case worries me a little.  (But in my understanding, some compile options would work to turn off inlining operator new, wouldn't it?)  I guess that speed-down by turning-off inlining should be acceptable since my approach has already have a similar speed-down.
>  
> Another option would be to add an LLVM instrumentation pass that runs on unoptimized code.  This is the sort of thing that should be achievable with a plugin, although I don't know if that's currently true.
> 
> Can we instrument by plug-in at the LLVM-level?  If so, that's also sounds like a reasonable way.
>  
> John.
> 
> 
> 
> -- 
> Dai MIKURUBE
>    dmikurube at acm.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130205/9e8deadd/attachment.html>