<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=koi8-r">
<style type="text/css" style="display:none"><!-- p { margin-top: 0px; margin-bottom: 0px; }--></style>
</head>
<body dir="ltr" style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p></p>
<div dir="ltr" style="font-size:12pt; color:#000000; background-color:#FFFFFF; font-family:Calibri,Arial,Helvetica,sans-serif">
<div>
<div>I performed tests basing on first diff of https://reviews.llvm.org/D40352.</div>
<div>(Creates .eh_frame for each .text.*, sets SHF_LINK_ORDER and .sh_link of created</div>
<div>.eh_frame section to point to corresponding .text.)</div>
<div><br>
</div>
<div>With use of GNU ld (GNU Binutils) 2.29.51.20171006 it reports errors when linking sample apps:</div>
<div>~/LLVM/Release/bin/clang++ test.cpp -ffunction-sections -o test.o</div>
<div>/usr/local/bin/ld: .eh_frame has both ordered [`.eh_frame' in /tmp/test-dbc52e.o] and unordered </div>
<div> [`.eh_frame' in /usr/lib/gcc/x86_64-linux-gnu/5.4.1/../../../x86_64-linux-gnu/crt1.o] sections</div>
<div>/usr/local/bin/ld: final link failed: Bad value</div>
<div><br>
</div>
<div>Looks it's code explicitly restricts mixing sections with link order flag and without:</div>
<div>https://github.com/gittup/binutils/blob/gittup/bfd/elflink.c#L9991</div>
<div><br>
</div>
<div>With GNU gold (GNU Binutils 2.29.51.20171006) 1.14 have an assert:</div>
<div>~/LLVM/Release/bin/clang++ test.cpp -ffunction-sections -o test.o</div>
<div>/usr/local/bin/ld: internal error in layout_eh_frame_section, at .././../gold/object.cc:1309</div>
<div>It is that place: https://github.com/gittup/binutils/blob/gittup/gold/object.cc#L1372</div>
<div>Did not investigate it, but it looks it is place (https://sourceware.org/ml/binutils/2009-06/msg00097.html) </div>
<div>mentioned in comment for https://marc.info/?l=llvm-commits&m=144683596826489.</div>
<div><br>
</div>
<div>LLD ~head fails here https://github.com/llvm-mirror/lld/blob/master/ELF/InputFiles.cpp#L392 as</div>
<div>we are trying to <span style="font-size: 12pt;">do cast to InputSection, though .eh_frame is not regular InputSection but EhInputSection.</span></div>
<div><br>
</div>
<div>Basing on all above I supposed it should be fine to not emit SHF_LINK_ORDER flags for start.</div>
<div>I changed implementation so that it emits multiple .eh_frames and sets sh_link field for</div>
<div>SHT_X86_64_UNWIND sections, <span style="font-size: 12pt;">but don't set the SHF_LINK_ORDER flag. In that way only</span></div>
<div><span style="font-size: 12pt;">x64 target is affected and SHT_X86_64_UNWIND sections </span><span style="font-size: 12pt;">a</span><span style="font-size: 12pt;">re known to be .eh_frame so can be</span></div>
<div><span style="font-size: 12pt;">handled on linker side not by name, what is also nice for start it seems.</span></div>
<div>(Uploaded current version as diff 2 here: https://reviews.llvm.org/D40352)</div>
<div><br>
</div>
<div>With such change LLD and bfd links fine, and I was able to test clang link time. Clang does not</div>
<div>use exceptions, <span style="font-size: 12pt;">but x64 ABI still requires .eh_frame sections for functions, and result objects</span></div>
<div><span style="font-size: 12pt;">contains many of them so </span><span style="font-size: 12pt;">I think it is reasonable test. What I did: built clang with and without</span></div>
<div><span style="font-size: 12pt;">patch, used result compiler binaries </span><span style="font-size: 12pt;">f</span><span style="font-size: 12pt;">or producing 2 sets of release clang objects</span></div>
<div><span style="font-size: 12pt;">(flags were -fPIC -std=c++11 -ffunction-sections -fdata-sections), </span><span style="font-size: 12pt;">used them for testing link time</span></div>
<div><span style="font-size: 12pt;">with use </span><span style="font-size: 12pt;">of ld.bfd and LLD.</span></div>
<div><br>
</div>
<div>Results (30 runs for each):</div>
<div>1) ld.bfd link time before patch: 2,922310802 seconds time elapsed ( +- 0,13% )</div>
<div> Size: 80 667 832 bytes </div>
<div>2) ld.bfd link time after patch: 3,773565826 seconds time elapsed ( +- 0,13% )</div>
<div> Size: 80 667 832 bytes </div>
<div>3) LLD link time before patch: 0,419247946 seconds time elapsed ( +- 0,48% )</div>
<div> Size: 80 738 240 bytes</div>
<div>4) LLD link time after patch: 0,460139012 seconds time elapsed ( +- 0,44% )</div>
<div> Size: 80 738 240 bytes</div>
<div><br>
</div>
<div>There is no difference in size (that is probably expected as linkers do deduplication optimization, so looks right for me),</div>
<div>slowdown for bfd is about 29%, for LLD about 9.7%.<br>
</div>
<div><br>
</div>
<div>What we gonna do next ? My plan is to prepare demo patch for LLD to stop parsing .eh_frames</div>
<div>for GC step and benchmark the results with use of -gc-sections. It also can show amount of LLD </div>
<div>code reduction/simplification we can have.<br>
</div>
<p><br>
</p>
<p>George.<br>
</p>
</div>
</div>
</body>
</html>