[PATCH] Intercept allocation to skim allocated types

Dai MIKURUBE dmikurube at acm.org
Tue Feb 26 16:47:57 PST 2013


Hi John,

Thank you for your reply.


2013/2/27 John McCall <rjmccall at apple.com>

> On Feb 24, 2013, at 12:38 AM, Dai MIKURUBE <dmikurube at acm.org> wrote:
> > Hi Douglas and John,
> >
> > I started to try your approach, but I'm still not sure what it does, and
> still a little doubtful that it's easy to catch allocation by non-global
> (in-class) operator news.  When a project has 100 in-class operator news,
> doesn't it need to prepare 101 replacement functions?  If it needs, I think
> it's so unrealistic.  We cannot track all changes in a big project (e.g.
> WebKit).  If a developer adds a new class with its local operator new, it's
> impossible to track all such local operator news.
> >
> > Could you tell me make sure 1) what should happen in the compiler and 2)
> what replacement functions should be added, in the simple example below?
> >
> > (Also, I'd like to know where is the DWARF code in Clang you mentioned.)
>
> Okay, here's the deal.
>
> I don't think we're really interested in taking your original language
> extension into mainline clang.  It's invasive, it's complicated, it's
> novel, and it doesn't seem to have broad applicability.
>
> Yes and yes, your point on my original extension is right at all.  I also
think it's complicated.  (So, I asked about it at cfe-dev@ weeks ago,
before I started implementing for upstream since I was worried about its
complicacy.)

I don't want to stick on my original proposal, and I don't want to
contradict your suggestion.  I *just* wanted hints to understand Douglas's
suggestion (maybe just simple answers to my questions) since I didn't
well-understand how his suggestion should be implemented and how the
implementation should work.  If it's not enough for our purpose, I'll think
out another idea.  Or, any other suggestions are also welcome.

What do you think, Douglas?



> Doug and I were suggesting adding infrastructure to LLVM under which
> arbitrary calls could be annotated with metadata which would potentially
> survive into DWARF.  This would be a broadly-applicable feature that could
> be used by potentially many projects.  This would be a lot of work on your
> part, but as a carrot, we would be open to an extension which merely
> annotates an operator new call using this new LLVM feature.  It may not,
> however, actually achieve your purposes that well;  I don't know them well
> enough to speculate.
>
> Ultimately, however, this is an open-source project, and you are welcome
> to maintain your patch out-of-tree.
>
> John.
>



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


More information about the cfe-commits mailing list