<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>Oke so this turned out to be caused by the presence of .debug_info, which pulled in the methods, and those pulled in the types. It seems just referencing a .lib with .obj that have (dwarf) debug info makes it pull in a lot of stuff. But at the very least, I now know what to avoid. Thanks!<br></div><div><br></div><div>On Fri, Jun 7, 2019, at 21:37, Zachary Turner wrote:<br></div><blockquote type="cite" id="qt"><div dir="ltr">You could try analyzing the PDB file using llvm-pdbutil. We won't add any symbols to the PDB that were eliminated by linker gc, so this should at least allow you to get a good idea of what symbols are actually contributing to the output. It won't give you a full dependency graph like Rui suggests, but it might be a good starting point.<br></div><div><br></div><div class="qt-gmail_quote"><div class="qt-gmail_attr" dir="ltr">On Fri, Jun 7, 2019 at 6:42 AM Carlo Kok via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-color:rgb(204, 204, 204);border-left-style:solid;border-left-width:1px;padding-left:1ex;" class="qt-gmail_quote"><div><u></u><br></div><div><div>I did try that yes. Didn't seem to make any difference (still 80ishmb)<br></div><div><br></div><div>On Fri, Jun 7, 2019, at 15:29, David Major wrote:<br></div><blockquote id="qt-gmail-m_3926876122193233518qt" type="cite"><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.<br></div><div><br></div></div><div><br></div><div class="qt-gmail-m_3926876122193233518qt-gmail_quote"><div dir="ltr" class="qt-gmail-m_3926876122193233518qt-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="qt-gmail-m_3926876122193233518qt-gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-color:rgb(204, 204, 204);border-left-style:solid;border-left-width:1px;padding-left:1ex;"><div><u></u><br></div><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="qt-gmail-m_3926876122193233518qt-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="qt-gmail-m_3926876122193233518qt-gmail-m_-9044509807864445141qt-gmail_quote"><div class="qt-gmail-m_3926876122193233518qt-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">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-color:rgb(204, 204, 204);border-left-style:solid;border-left-width:1px;padding-left:1ex;" class="qt-gmail-m_3926876122193233518qt-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">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">llvm-dev@lists.llvm.org</a><br></div><div><a rel="noreferrer" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br></div></blockquote></div></blockquote><div><br></div></div><div>_______________________________________________<br></div><div>LLVM Developers mailing list<br></div><div><a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br></div><div><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br></div></blockquote></div></blockquote><div><br></div></div><div>_______________________________________________<br></div><div> LLVM Developers mailing list<br></div><div> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br></div><div> <a rel="noreferrer" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br></div></blockquote></div></blockquote><div><br></div></body></html>