[PATCH] Intercept allocation to skim allocated types

[Dai MIKURUBE]

Thank you, Douglas.

Ok, I'll give it a try.  I think it'll take a few weeks.  I may ask more
questions later since I might not understand this design well.


2013/2/6 Douglas Gregor <dgregor at apple.com>

>
> 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
>
>
>


-- 
Dai MIKURUBE
   dmikurube at acm.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130207/38e69012/attachment.html>