<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);">
I was thinking keeping both structures for backward compatibility in case object files with old representation are fed in to new llvm-objdump, and even lld. For example if someone will use older clang release with lld/llvm-objdump after this change.<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);">
For just changing the value and keeping the name. Looks like it will leave a gap in this sequential sequence. If a new flag is added later down the road and in this case latest clang used with older lld/llvm-objdump this will also present a problem as older
tools will interpret new flag as SHT_LLVM_CALL_GRAPH_PROFILE.<br>
Not sure if these are valid concerns, what do you think?<br>
If we go for clean state, then maybe leave <span style="color: rgb(181, 206, 168); font-family: Menlo, Monaco, "Courier New", monospace; font-size: 12px; background-color: rgb(30, 30, 30); display: inline !important;">0x6fff4c02</span> entry and change it to
SHT_LLVM_CALL_GRAPH_PROFILE_DEPRICATED, and emit warning if objects with it are passed in.<br>
<div style="color: rgb(212, 212, 212); background-color: rgb(30, 30, 30); font-family: Menlo, Monaco, "Courier New", monospace; font-weight: normal; font-size: 12px; line-height: 18px;">
<span><span> </span><span style="color: rgb(79, 193, 255);">SHT_LLVM_ODRTAB</span><span> =
</span><span style="color: rgb(181, 206, 168);">0x6fff4c00</span><span>,</span><span style="color: rgb(106, 153, 85);"> // LLVM ODR table.</span></span>
<div><span> </span><span style="color: rgb(79, 193, 255);">SHT_LLVM_LINKER_OPTIONS</span><span> =
</span><span style="color: rgb(181, 206, 168);">0x6fff4c01</span><span>,</span><span style="color: rgb(106, 153, 85);"> // LLVM Linker Options.</span></div>
<div><span> </span><span style="color: rgb(79, 193, 255);">SHT_LLVM_CALL_GRAPH_PROFILE</span><span> =
</span><span style="color: rgb(181, 206, 168);">0x6fff4c02</span><span>,</span><span style="color: rgb(106, 153, 85);"> // LLVM Call Graph Profile.</span></div>
<div><span> </span><span style="color: rgb(79, 193, 255);">SHT_LLVM_ADDRSIG</span><span> =
</span><span style="color: rgb(181, 206, 168);">0x6fff4c03</span><span>,</span><span style="color: rgb(106, 153, 85);"> // List of address-significant symbols</span></div>
<div><span style="color: rgb(106, 153, 85);"> // for safe ICF.</span></div>
<div><span> SHT_LLVM_DEPENDENT_LIBRARIES =</span></div>
<div><span> 0x6fff4c04,</span><span style="color: rgb(106, 153, 85);"> // LLVM Dependent Library Specifiers.</span></div>
<div><span> </span><span style="color: rgb(79, 193, 255);">SHT_LLVM_SYMPART</span><span> =
</span><span style="color: rgb(181, 206, 168);">0x6fff4c05</span><span>,</span><span style="color: rgb(106, 153, 85);"> // Symbol partition specification.</span></div>
<div><span> </span><span style="color: rgb(79, 193, 255);">SHT_LLVM_PART_EHDR</span><span> =
</span><span style="color: rgb(181, 206, 168);">0x6fff4c06</span><span>,</span><span style="color: rgb(106, 153, 85);"> // ELF header for loadable partition.</span></div>
<div><span> </span><span style="color: rgb(79, 193, 255);">SHT_LLVM_PART_PHDR</span><span> =
</span><span style="color: rgb(181, 206, 168);">0x6fff4c07</span><span>,</span><span style="color: rgb(106, 153, 85);"> // Phdrs for loadable partition.</span></div>
<span><span> </span><span style="color: rgb(79, 193, 255);">SHT_LLVM_BB_ADDR_MAP</span><span> =
</span><span style="color: rgb(181, 206, 168);">0x6fff4c08</span><span>,</span><span style="color: rgb(106, 153, 85);"> // LLVM Basic Block Address Map.</span></span></div>
<br>
</div>
<div id="appendonsend"></div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size: 11pt;"><b>From:</b> maskray@google.com <maskray@google.com><br>
<b>Sent:</b> Thursday, May 27, 2021 11:27 AM<br>
<b>To:</b> Alexander Yermolovich <ayermolo@fb.com><br>
<b>Cc:</b> llvm-dev@lists.llvm.org <llvm-dev@lists.llvm.org>; Wenlei He <wenlei@fb.com>; Modi Mo <modimo@fb.com>; dblaikie@gmail.com <dblaikie@gmail.com><br>
<b>Subject:</b> Re: [RFC] Changing .llvm.call-graph-profile to use relocations</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="PlainText">On 2021-05-27, Alexander Yermolovich wrote:<br>
>Thank you for feedback, let me try to use R_X86_64_NONE, and introduce another type. . I thought R_X86_64_32 would be less impactful as structure of is preserved, but it is space wasteful.<br>
>For type name: ELF::SHT_LLVM_CALL_GRAPH_PROFILE_RELA ?<br>
><br>
>Alex<br>
<br>
Preversing the structure is not needed because the symbol representation<br>
is changed anyway.<br>
<br>
You just need to change the value in<br>
llvm/llvm/include/llvm/BinaryFormat/ELF.h<br>
The name doesn't need to change.<br>
<br>
>From: maskray@google.com <maskray@google.com><br>
>Sent: Wednesday, May 26, 2021 5:03 PM<br>
>To: Alexander Yermolovich <ayermolo@fb.com><br>
>Cc: llvm-dev@lists.llvm.org <llvm-dev@lists.llvm.org>; Wenlei He <wenlei@fb.com>; Modi Mo <modimo@fb.com>; dblaikie@gmail.com <dblaikie@gmail.com><br>
>Subject: Re: [RFC] Changing .llvm.call-graph-profile to use relocations<br>
><br>
>On 2021-05-26, Alexander Yermolovich wrote:<br>
>>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>
>><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>
>Yes, a relocation based approach will be more robust and can fix the<br>
>.llvm_addrsig issue <a href="https://sourceware.org/bugzilla/show_bug.cgi?id=23817">https://sourceware.org/bugzilla/show_bug.cgi?id=23817</a>
<br>
><br>
>The relocation type doesn't matter. Your implementation uses R_X86_64_32 and from/to/value/from/to/value/from/to/value<br>
>An alternative design is R_X86_64_NONE + value/value/value, i.e. from/to do not occupy space in the content.<br>
>We will get a 3x space saving.<br>
><br>
>We need to change the section type since changing representation is incompatible<br>
>and the sections from old object files should be ignored.<br>
>The new section type will be ignored by old LLVM tools as well.<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>
>>"This section is excluded from input to the link-edit of an executable or shared object. This flag is ignored if the SHF_ALLOC flag is also set, or if relocations exist against the section."<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">https://reviews.llvm.org/D24966</a>
<br>
><br>
>This is Solaris's spec (since 1996), not standard ELF's. It can be advisory but<br>
>our behavior (mostly GNU ABI+Linux ABI+LLVM extensions) does not necessarily<br>
>follow it. I cannot find a definition in the x86-64 psABI or a GNU ABI<br>
>document.<br>
><br>
>I think the behavior as implemented in gold and LLD is more useful.<br>
><br>
>>Finally, this bug seems similar to <a href="https://sourceware.org/bugzilla/show_bug.cgi?id=23817">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">https://reviews.llvm.org/D103212</a>
<br>
</div>
</span></font></div>
</body>
</html>