<div dir="ltr"><a class="gmail_plusreply" id="plusReplyChip-2" href="mailto:hoy@fb.com" tabindex="-1">+hoy@fb.com</a> to bring them into the thread<br><div><br></div><div>That kind of static function could probably be brought out into a different library, but I think for this some sort of agreement on the dependency chains would be really helpful with what each library is bringing to the table here. It might make more sense for the MC work that's been going on here to be happening in ProfileData with that depending on Object and MC to get work done.</div><div><br></div><div>Thanks!</div><div><br></div><div>-eric</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 9, 2021 at 2:42 PM Nagurne, James via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US">
<div class="gmail-m_-5121979616895690931WordSection1">
<p class="MsoNormal">Hi all,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Some background: our team has added Object to the LINK_COMPONENTS of  the ProfileData library as part of work to support code coverage on baremetal emebdded devices.<u></u><u></u></p>
<p class="MsoNormal">Specifically, there is a new type of InstrProfReader that opens an executable and extracts unallocated sections as metadata, rather than relying on a heavyweight runtime call and metadata sections living in restricted target memory.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Recently, commit ee7d20e8 (<a href="https://reviews.llvm.org/D106861" target="_blank">https://reviews.llvm.org/D106861</a>) added a dependency on the ProfileData library to the MC library.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">The combination of these changes causes a dependency circuit that results in link-time failures:<u></u><u></u></p>
<ul style="margin-top:0in" type="disc">
<li class="gmail-m_-5121979616895690931MsoListParagraph" style="margin-left:0in">MC depends on ProfileData<u></u><u></u></li><li class="gmail-m_-5121979616895690931MsoListParagraph" style="margin-left:0in">ProfileData depends on Object<u></u><u></u></li><li class="gmail-m_-5121979616895690931MsoListParagraph" style="margin-left:0in">Object depends on MC<u></u><u></u></li></ul>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Is there any good way to resolve such dependency circuits in the build system save for an invasive restructuring?<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I’ll note that in the review above, MCPseudoProbe only relies upon the static member function FunctionSamples::getCanonicalFnName, which itself relies on a number of static data members of FunctionSamples.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Regards,<u></u><u></u></p>
<p class="MsoNormal">J.B. Nagurne<u></u><u></u></p>
<p class="MsoNormal">Code Generation<u></u><u></u></p>
<p class="MsoNormal">Texas Instruments<u></u><u></u></p>
</div>
</div>

_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>