<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
Currently when .llvm.call-graph-profile is created by llvm it explicitly encodes the symbol indices. This section is basically a black box for post processing tools. For example, if we run strip -s on the object files the symbol table changes, but indices in
that section do not.<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<br>
We propose to change this section to use relocations. The Frequency will still be in the .llvm.call-graph-profile, but symbol information will be in relocation section. In LLD information from both sections is used to reconstruct call graph profile. Relocations
themselves will never be applied.<br>
<br>
With this approach post processing tools that handle relocations correctly work for this section also.<br>
<br>
One thing is section is marked with SHF_EXCLUDE. <br>
>From spec<br>
"<span style="color: rgb(0, 0, 0); font-family: Times; font-size: medium; display: inline !important;">This section is excluded from input to the link-edit of an executable or shared object. This flag is ignored if the<span> </span></span><tt style="color: rgb(0, 0, 0);">SHF_ALLOC</tt><span style="color: rgb(0, 0, 0); font-family: Times; font-size: medium; display: inline !important;"><span> </span>flag
is also set, or if relocations exist against the section.</span>"<br>
<br>
So technically speaking it needs to be kept, and presumably relocations applied, but LLD follows gold and ld and discards sections marked as SHF_EXCLUDE even with relocations. So, I think this approach should be fine. <a href="https://reviews.llvm.org/D24966" id="LPlnk564873">https://reviews.llvm.org/D24966</a><br>
<br>
Finally, this bug seems similar to <a href="https://sourceware.org/bugzilla/show_bug.cgi?id=23817" id="LPlnk758061">https://sourceware.org/bugzilla/show_bug.cgi?id=23817</a>. Proposed solution for that was also to use relocations.<br>
<br>
Implementation: <a href="https://reviews.llvm.org/D103212" id="LPlnk467279">https://reviews.llvm.org/D103212</a></div>
</body>
</html>