<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hello Dai,<div><br></div><div>Eric Christopher has a ton of knowledge about this area of the compiler. I think he'll be able to help more than I.</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div><br><div><div>On Mar 18, 2013, at 2:30 AM, Dai MIKURUBE <<a href="mailto:dmikurube@acm.org">dmikurube@acm.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;">Hi John and Douglas,<br><br>Sorry for my mails a lot of times, but I found that just the first<br>part of your suggestion would work enough for our purpose!<br><br>It works for our purpose only with the association of 1) the type of a<br>particular "new" expression and 2) the address at which the call to<br>operator new occurs (DWARF does this sort of thing) as you suggested.<br>It's because we already have a malloc profiler, and we focus on<br>malloc'ed memory blocks. A result of the malloc profiler should have<br>the address at which the call to operator new occurs.<br><br><br>Could you introduce the expected reviewer for that? I think I'll be<br>starting to implement your suggestion soon, but I'd like to discuss<br>the rough design and how to implement it before starting.<br><br># I wonder if I could attend the next LLVM devmtg, and talk about it<br>with him or her face-to-face quickly.<br><br>2013/2/27 Dai MIKURUBE <<a href="mailto:dmikurube@acm.org">dmikurube@acm.org</a>>:<br><blockquote type="cite">Hi John,<br><br>Thank you for your reply.<br><br><br>2013/2/27 John McCall <<a href="mailto:rjmccall@apple.com">rjmccall@apple.com</a>><br><blockquote type="cite"><br>On Feb 24, 2013, at 12:38 AM, Dai MIKURUBE <<a href="mailto:dmikurube@acm.org">dmikurube@acm.org</a>> wrote:<br><blockquote type="cite">Hi Douglas and John,<br><br>I started to try your approach, but I'm still not sure what it does, and<br>still a little doubtful that it's easy to catch allocation by non-global<br>(in-class) operator news. When a project has 100 in-class operator news,<br>doesn't it need to prepare 101 replacement functions? If it needs, I think<br>it's so unrealistic. We cannot track all changes in a big project (e.g.<br>WebKit). If a developer adds a new class with its local operator new, it's<br>impossible to track all such local operator news.<br><br>Could you tell me make sure 1) what should happen in the compiler and 2)<br>what replacement functions should be added, in the simple example below?<br><br>(Also, I'd like to know where is the DWARF code in Clang you mentioned.)<br></blockquote><br>Okay, here's the deal.<br><br>I don't think we're really interested in taking your original language<br>extension into mainline clang. It's invasive, it's complicated, it's novel,<br>and it doesn't seem to have broad applicability.<br><br></blockquote>Yes and yes, your point on my original extension is right at all. I also<br>think it's complicated. (So, I asked about it at cfe-dev@ weeks ago, before<br>I started implementing for upstream since I was worried about its<br>complicacy.)<br><br>I don't want to stick on my original proposal, and I don't want to<br>contradict your suggestion. I *just* wanted hints to understand Douglas's<br>suggestion (maybe just simple answers to my questions) since I didn't<br>well-understand how his suggestion should be implemented and how the<br>implementation should work. If it's not enough for our purpose, I'll think<br>out another idea. Or, any other suggestions are also welcome.<br><br>What do you think, Douglas?<br><br><br><blockquote type="cite"><br>Doug and I were suggesting adding infrastructure to LLVM under which<br>arbitrary calls could be annotated with metadata which would potentially<br>survive into DWARF. This would be a broadly-applicable feature that could<br>be used by potentially many projects. This would be a lot of work on your<br>part, but as a carrot, we would be open to an extension which merely<br>annotates an operator new call using this new LLVM feature. It may not,<br>however, actually achieve your purposes that well; I don't know them well<br>enough to speculate.<br><br>Ultimately, however, this is an open-source project, and you are welcome<br>to maintain your patch out-of-tree.<br><br>John.<br></blockquote><br><br><br><br>--<br>Dai MIKURUBE<br> <a href="mailto:dmikurube@acm.org">dmikurube@acm.org</a><br></blockquote><br><br><br>--<br>Dai MIKURUBE<br> <a href="mailto:dmikurube@acm.org">dmikurube@acm.org</a></div></blockquote></div><br></div></body></html>