<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msonormal00, li.msonormal00, div.msonormal00
{mso-style-name:msonormal0;
margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msochpdefault, li.msochpdefault, div.msochpdefault
{mso-style-name:msochpdefault;
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
span.emailstyle19
{mso-style-name:emailstyle19;
font-family:"Calibri",sans-serif;
color:windowtext;
font-weight:normal;
font-style:normal;}
span.EmailStyle23
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;
font-weight:normal;
font-style:normal;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal" style="background:white"><span style="color:#212121">> But if we still need to deal with CIEs and generate .eh_frame_hdr in a special way,<o:p></o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="color:#212121">> does it make sense to make this change to simplify only a small part of a linker?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">For huge C++ projects this could improve link time if GC is a bottleneck. It will also improve eh_frame_hdr build time because you don’t spend time on parsing garbage. However a linker will have
to have two versions of GC: one with parsing eh_frames and another without parsing. There can be input object files where .eh_frame is not split.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">-Evgeny<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">Igor Kudrin <ikudrin@accesssoftek.com><br>
<b>Date: </b>Friday, 10 November 2017 at 12:23<br>
<b>To: </b>Evgeny Astigeevich <Evgeny.Astigeevich@arm.com><br>
<b>Cc: </b>nd <nd@arm.com>, "llvm-dev@lists.llvm.org" <llvm-dev@lists.llvm.org><br>
<b>Subject: </b>Re: [llvm-dev] [RFC] Making .eh_frame more linker-friendly<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p>Hi Evgeny,<o:p></o:p></p>
<p><o:p> </o:p></p>
<p class="MsoNormal" style="background:white"><span style="color:#212121">> Yes, a linker needs some details but not all of them. It needs to know sizes of records and initial locations (PC Begin) to find out which functions FDEs belong to.<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><br>
So, it still needs some details. Not all of them, but anyway, handling of .eh_frame sections is still a special case, even if we split all the content at compile time.<o:p></o:p></p>
</div>
<p><o:p> </o:p></p>
<p class="MsoNormal" style="background:white"><span style="color:#212121">> What do you mean “one place or two”?<o:p></o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="color:#212121"><o:p> </o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="color:#212121">If I understand it right, the RFC is about helping a linker to eliminate unneeded .eh_frame items when performing GC. But if we still need to deal with CIEs and generate .eh_frame_hdr
in a special way, does it make sense to make this change to simplify only a small part of a linker?<o:p></o:p></span></p>
<p class="MsoNormal" style="background:white"><span style="color:#212121"><o:p> </o:p></span></p>
<div id="Signature">
<div name="divtagdefaultwrapper">
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:10.5pt;color:#212121">Best Regards,</span><span style="font-size:11.5pt;font-family:"Tahoma",sans-serif;color:#212121"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span lang="EN-US" style="font-size:10.5pt;color:#212121">Igor Kudrin</span><span style="font-size:11.5pt;font-family:"Tahoma",sans-serif;color:#212121"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span lang="EN-US" style="font-size:10.5pt;color:#212121">C++ Developer,</span><span style="color:#212121"> Access Softek, Inc.</span><span style="font-size:11.5pt;font-family:"Tahoma",sans-serif;color:#212121"><o:p></o:p></span></p>
</div>
</div>
</div>
<div>
<div class="MsoNormal" align="center" style="text-align:center"><span style="color:#212121">
<hr size="2" width="98%" align="center">
</span></div>
<div id="divRplyFwdMsg">
<p class="MsoNormal"><b><span style="color:black">From:</span></b><span style="color:black"> llvm-dev <llvm-dev-bounces@lists.llvm.org> on behalf of Evgeny Astigeevich via llvm-dev <llvm-dev@lists.llvm.org><br>
<b>Sent:</b> Friday, November 10, 2017 6:41 PM<br>
<b>To:</b> Igor Kudrin<br>
<b>Cc:</b> llvm-dev@lists.llvm.org; nd<br>
<b>Subject:</b> Re: [llvm-dev] [RFC] Making .eh_frame more linker-friendly</span><span style="color:#212121">
<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="color:#212121"> <o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:#212121">Hi Igor,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#212121"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#212121">> It sounds like the linker has to be aware of the .eh_frame section details to be able to generate .eh_frame_hdr and eliminate duplicate CIEs, right?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#212121"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#212121">Yes, a linker needs some details but not all of them. It needs to know sizes of records and initial locations (PC Begin) to find out which functions FDEs belong to.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#212121"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#212121">> So, is there any difference whether it knows that in one place or two?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#212121"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#212121">What do you mean “one place or two”? If .eh_frame_hdr is not created a linker does not need to parse .eh_frame sections. It simply merges them into one section. The format of .eh_frame allows to do this without
parsing .eh_frame sections.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#212121"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#212121">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#212121">Evgeny Astigeevich<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#212121"> <o:p></o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">Igor Kudrin <ikudrin.dev@gmail.com><br>
<b>Date: </b>Thursday, 9 November 2017 at 11:29<br>
<b>To: </b>Rui Ueyama <ruiu@google.com>, Evgeny Astigeevich <Evgeny.Astigeevich@arm.com><br>
<b>Cc: </b>"llvm-dev@lists.llvm.org" <llvm-dev@lists.llvm.org>, nd <nd@arm.com><br>
<b>Subject: </b>Re: [llvm-dev] [RFC] Making .eh_frame more linker-friendly</span><span style="color:#212121"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#212121"> <o:p></o:p></span></p>
</div>
<p><a name="_MailOriginalBody"><span style="color:#212121">It sounds like the linker has to be aware of the .eh_frame section details to be able to generate .eh_frame_hdr and eliminate duplicate CIEs, right?<o:p></o:p></span></a></p>
<p><span style="mso-bookmark:_MailOriginalBody"><span style="color:#212121">So, is there any difference whether it knows that in one place or two?<o:p></o:p></span></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="mso-bookmark:_MailOriginalBody"><span style="color:#212121">Best Regards,<br>
Igor Kudrin<br>
C++ Developer, Access Softek, Inc.<o:p></o:p></span></span></p>
<div>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"><span style="color:#212121">On 27-Oct-17 3:43, Rui Ueyama via llvm-dev wrote:<o:p></o:p></span></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"><span style="color:#212121">On Thu, Oct 26, 2017 at 1:13 PM, Evgeny Astigeevich <</span></span><a href="mailto:Evgeny.Astigeevich@arm.com" target="_blank"><span style="mso-bookmark:_MailOriginalBody">Evgeny.Astigeevich@arm.com</span><span style="mso-bookmark:_MailOriginalBody"></span></a><span style="mso-bookmark:_MailOriginalBody"><span style="color:#212121">>
wrote:<o:p></o:p></span></span></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"><span style="color:#212121">Hi,<o:p></o:p></span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"><span style="color:#212121"> <o:p></o:p></span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"><span style="color:#212121">There will be problems with eh_frame_hdr. Eh_frame_hdr is needed to use the binary search instead of the linear search. Having eh_frame per a function will cause no
eh_frame_hdr or multiple eh_frame_hdr and will degrade search from binary to linear.<o:p></o:p></span></span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"><span style="color:#212121"> <o:p></o:p></span></span></p>
</div>
<div>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"><span style="color:#212121">Linkers would combine .eh_frame sections into one .eh_frame, so that's not an issue, no?<o:p></o:p></span></span></p>
</div>
<div>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"><span style="color:#212121"> <o:p></o:p></span></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"><span style="color:#212121">As we create eh_frame_hdr in most cases there is no problem to filter out garbage eh_frame sections. If there is information about unused symbols, the implementation
is very simple. BTW there is no need to do full decoding of eh_frame records to remove garbage.<o:p></o:p></span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"><span style="color:#212121">Paul is right there will be code size overhead. Eh_frame is usually created per a compilation module with common information in CFI. Multiple eh_frames will cause
a lot of redundant CFI. There might be a case when the total size of redundant CFIs will be greater than the total size of removed garbage.<o:p></o:p></span></span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"><span style="color:#212121"> <o:p></o:p></span></span></p>
</div>
<div>
<p class="MsoNormal"><span style="mso-bookmark:_MailOriginalBody"><span style="color:#212121">As I wrote in the previous message, I don't think there's a size issue in link results because even existing linkers merge CIEs by contents.</span></span><span style="color:#212121"><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</body>
</html>