<div>Sorry it's taken me a bit to circle back to this problem...</div><div><br></div>On Wed, Jul 25, 2012 at 2:34 PM, Nuno Lopes <span dir="ltr"><<a href="mailto:nunoplopes@sapo.pt" target="_blank" class="cremed">nunoplopes@sapo.pt</a>></span> wrote:<br>
<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Quoting Benjamin Kramer <<a href="mailto:benny.kra@gmail.com" class="cremed">benny.kra@gmail.com</a>>:<br>

<br>
> On 25.07.2012, at 22:24, Nuno Lopes <<a href="mailto:nunoplopes@sapo.pt" class="cremed">nunoplopes@sapo.pt</a>> wrote:<br>
><br>
>> Quoting Duncan Sands <<a href="mailto:baldrick@free.fr" class="cremed">baldrick@free.fr</a>>:<br>
>><br>
>>> Hi Nuno,<br>
>>><br>
>>>> original commit msg:<br>
>>>> MemoryBuiltins: add support to determine the size of strdup'ed<br>
>>>> non-constant strings<br>
>>><br>
>>> the dragonegg bots don't use cmake but they broke too:<br>
>>><br>
>>> MemoryBuiltins.cpp:(.text+0x40dc): undefined reference to<br>
>>> `llvm::EmitStrNLen(llvm::Value*, llvm::Value*, llvm::IRBuilder<true,<br>
>>> llvm::ConstantFolder, llvm::IRBuilderDefaultInserter<true> >&,<br>
>>> llvm::TargetData<br>
>>> const*, llvm::TargetLibraryInfo const*)'<br>
>>> MemoryBuiltins.cpp:(.text+0x4207): undefined reference to<br>
>>> `llvm::EmitStrLen(llvm::Value*, llvm::IRBuilder<true, llvm::ConstantFolder,<br>
>>> llvm::IRBuilderDefaultInserter<true> >&, llvm::TargetData const*,<br>
>>> llvm::TargetLibraryInfo const*)'<br>
>><br>
>> Interesting.. I guess I need to try to build it on another machine.<br>
><br>
> Isn't using lib/Transforms/Utils from lib/Analysis a layering<br>
> violation (cyclic dependency)?<br>
<br>
</div>Well, I really need to access some functions from<br>
lib/Transforms/Utils. Is there any dependency of lib/Transforms/Utils<br>
on lib/Analysis?<br></blockquote><div><br></div><div>No, you simply cannot depend on lib/Transforms code from within lib/Analysis. That is a complete violation of the layering design here.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

I really don't have a clue on how to solve this problem.. :)<br></blockquote><div><br></div><div>I think the fundamental problem is that ObjectSizeOffsetEvaluator isn't an analysis, and shouldn't be in lib/Analysis at all. From its description:</div>
<div><br></div><div>"Evaluate the size and offset of an object pointed [to] by a value*. May create code to compute the result at run-time.". An Analysis pass shouldn't create code. The only consumer of this interface is lib/Transforms/Instrumentation/BoundsChecking.cpp, I think this class should move to an anonymous namespace within that instrumentation pass. If we want to hoist it, it could grow to live in lib/Transforms/Utils/ObjectSize.cpp or even lib/Transforms/Utils/MemoryBuiltins.cpp. I would only move it out of the anonymous namespace if you have a pretty strong idea that others will want to use the logic. I would only move it to a memory builtin utility file if you think its likely we'll want more general memory builtin transform utilities in the future.</div>
<div><br></div><div>Can I make at least the move to the anonymous namespace? I'd like to get the layering issue fixed.</div></div></div>