[PATCH] Intercept allocation to skim allocated types

[Dai MIKURUBE]

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?)
2) Who "associates" the type of a particular "new" expression with the
address?
3) Who "records" the association, and where is it recorded?


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/a3b1c3d5/attachment.html>