<div dir="ltr"><div>Just to double check: are you calling lld-link with `-opt:ref`? It may or may not be enabled by default, depending on other flags.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 7, 2019 at 8:26 AM Carlo Kok 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"><u></u><div><div>Unfortunately, lld link doesn't do -map yet (and link.exe /map is kinda useless; it shows what get linked in, but only refers to an object file, not function name when it does so, like a single reference in that object file triggers all it's dependencies)<br></div><div><br></div><div>Yeah I'm fairly sure it's caused by something I'm doing wrong, I just have no idea how to find out. I thought -function-section would have pretty much covered it.<br></div><div><br></div><div>On Fri, Jun 7, 2019, at 14:22, Rui Ueyama wrote:<br></div><blockquote type="cite" id="gmail-m_-9044509807864445141qt"><div dir="ltr"><div>If you use only one function from a static library, and that adds 80 MiB to the executable, it is clear that that undefined symbol causes a lot of other files to be loaded, so the question is why that function has such a large (transitive) dependency and how to find the cause.<br></div><div><br></div><div>Unfortunately there's no exact command line option or a feature to find it out. I have an idea to write a post-link analysis tool, which processes a linker's debug output, to find out a "weak link" in a dependency graph. If we can split a graph into two by removing a small number of symbols (or vertices) from the graph, we can reduce a program size by removing these symbols from the program. But that kind of analysis tool is not available yet, and I don't know how powerful it would actually be.<br></div><div><br></div><div>There are a few options that may be useful when debugging the issue.<br></div><div><br></div><div>`-v` makes lld to print out a file name as the linker loads a new file.<br></div><div><br></div><div>`-Map=<filename>` makes lld to write an output file layout information to a given file.<br></div></div><div><br></div><div class="gmail-m_-9044509807864445141qt-gmail_quote"><div class="gmail-m_-9044509807864445141qt-gmail_attr" dir="ltr">On Fri, Jun 7, 2019 at 8:59 PM Carlo Kok via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail-m_-9044509807864445141qt-gmail_quote"><div>Is there any way to find out what causes a 80mb executable with lld/link?<br></div><div> <br></div><div> <br></div><div> The object files are compiled with -function-sections and -data-sections, the originating .lib is 270mb, but I'm calling 1 function in it, which might call some stuff recursively, but I don't know how to find out what exactly triggers the use. Is there a commandline option that shows this?<br></div><div> <br></div><div> (repro is 286 mb) : <a rel="noreferrer" href="http://gofile.me/4Gflq/OOr8WKU12" target="_blank">http://gofile.me/4Gflq/OOr8WKU12</a><br></div><div> _______________________________________________<br></div><div> LLVM Developers mailing list<br></div><div> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br></div><div> <a rel="noreferrer" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br></div></blockquote></div></blockquote><div><br></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>