[PATCH] Intercept allocation to skim allocated types

[Dai MIKURUBE]

Hi Doug,


2013/2/7 Dai MIKURUBE <dmikurube at acm.org>

> 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.
>>
>> Would you tell me any good starting points to read in DWARF code if you
know?  I'd like to try it with using examples in Clang.

Thank you for your help.

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



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