<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
We discussed this internally and changed minds a few times. The debate isn’t settled and I am still open to opinions (but I will stop changing my code coding conventions back and forth until we reach an agreement :-)). My current take on it is that if the tool end up as just a thin wrapper around libDebugInfo (+ maybe some other libs depending on how we do the streaming), then there is little point in hosting it with lld. As a matter of fact, the tool doesn’t use lld concepts at all and I’m pretty confident that there would be zero code sharing with lld.<br>
<br>
Moreover, it is our long term goal to integrate the functionality in lld  (by linking lld with the library that provides the functionality), but today the linker never calls dsymutil. The clang driver does call it on darwin platforms when it generates temporary object files though, which IMO is another argument for having the utility hosted in LLVM proper.<br>
<br></blockquote><div><br></div><div>Seems like a good plan.</div><div><br></div><div>-eric</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Fred<br>
<br>
> Shankar Easwaran<br>
><br>
> --<br>
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation<br>
><br>
<br>
</blockquote></div>