[PATCH] Intercept allocation to skim allocated types
dmikurube at acm.org
Thu Feb 7 02:30:17 PST 2013
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?)
> 2) Who "associates" the type of a particular "new" expression with the
> 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
>> >> 1) Capture allocated types of as most objects as possible.
>> >> 2) No need to change almost all the existing code. Just adding some
>> >> 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
>> > 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.
> Dai MIKURUBE
> dmikurube at acm.org
dmikurube at acm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-commits