<html 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=gb2312">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.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>
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Thank you for reply<o:p></o:p></p>
<p class="MsoNormal">I understand the semantics of the relocation. My point is that my system currently builds and works without -fpic nor -fpie and the R_X86_64_GOTOFF64 relocation is not generated by clang itself and without -flto, everything works and that
is proof that this relocation is not essential for my application ... <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The problem is when I add -flto, lld¡¯s code generation unnecessarily generates code with this relocation. I¡¯m looking for an option to pass to lld (or the x86_64 lto plugin of lld) to keep it from doing that.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">A<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">F¨¡ng-ru¨¬ S¨°ng <maskray@google.com><br>
<b>Date: </b>Saturday, January 9, 2021 at 10:51 PM<br>
<b>To: </b>Moshtaghi, Alireza <Alireza.Moshtaghi@netapp.com><br>
<b>Cc: </b>llvm-dev@lists.llvm.org <llvm-dev@lists.llvm.org><br>
<b>Subject: </b>Re: [llvm-dev] (LLD / lto ) How to avoid GOT code generation<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal">NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.<br>
<br>
<br>
<br>
<br>
On Sat, Jan 9, 2021 at 10:45 PM F¨¡ng-ru¨¬ S¨°ng <maskray@google.com> wrote:<br>
><br>
> On Sat, Jan 9, 2021 at 12:03 PM Moshtaghi, Alireza via llvm-dev<br>
> <llvm-dev@lists.llvm.org> wrote:<br>
> ><br>
> > Hi<br>
> ><br>
> > I¡¯m generating a special shared object in x86_64 large memory model (-mcmodel=large).<br>
> ><br>
> > For this object, I pass -z notext to lld to leave the text relocations alone and normally it builds and works with no problem.<br>
> ><br>
> > But when I add link time optimization, lld generates R_X86_64_GOTOFF64 which stops itself from linking. (Note that when I objdump -r on my elf objects without lto, this relocation is not generated; but for some reason lld decides to treat the non pic lto
object as a pic object and generate got/pic code)<br>
> ><br>
> > How can I tell lld to not generate GOT / PIC code ?<br>
> ><br>
> ><br>
> ><br>
> > Here is the example:<br>
> ><br>
> > When I compile as follows, my shared lib is generated and works fine<br>
> ><br>
> > clang -mcmodel=large -o sample.o -c sample.c. # -flto=thin fails<br>
> ><br>
> > ld.lld -Bshareable -z notext -o out.so sample.o<br>
> ><br>
> ><br>
> ><br>
> > but when I compile with -flto=thin, lld errors that R_X86_64_GOTOFF64 can¡¯t be used against foo and foo_call and wants me to compile with -fPIC but I don¡¯t want to use PIC and GOT<br>
> ><br>
> ><br>
> ><br>
> > sample.c :<br>
> ><br>
> > extern int foo;<br>
> ><br>
> > int* bar = &foo;<br>
> ><br>
> ><br>
> ><br>
> > int foo_call (int, int *);<br>
> ><br>
> ><br>
> ><br>
> > int foo_call (int a, int *b) {<br>
> ><br>
> > return a+ *b;<br>
> ><br>
> > }<br>
> ><br>
> ><br>
> ><br>
> > int dummy (void) {<br>
> ><br>
> > int *fooptr = &foo;<br>
> ><br>
> > return foo_call (1, fooptr);<br>
> ><br>
> > }<br>
><br>
> clang -fpic -flto -mcmodel=large -o sample.o -c sample.c will work.<br>
><br>
> Your compile mode is -fno-pic (Clang default for Linux), which can<br>
> only be linked in -no-pie mode.<br>
> -fpie is compatible with -no-pie and -pie.<br>
> -fpic is compatible with -no-pie, -pie and -shared (-Bsharable).<br>
><br>
> -fno-pic + -shared can sometimes work, work in more cases with -z<br>
> notext, but still not always.<br>
><br>
> For this case: the formula for R_X86_64_GOTOFF64 is S+A-GOT where S<br>
> represents the symbol value.<br>
> Since foo is undefined, the relocation cannot be resolved at link<br>
> time. LLD does not produce a dynamic relocation<br>
> because R_X86_64_GOTOFF64 is not a generally acceptable dynamic<br>
> relocation type by ld.so implementations.<br>
<br>
I'd say R_X86_64_GOTOFF64 is a direct access relocation type, not a<br>
GOT indirection relocation type.<br>
<br>
A GOT indirection relocation type should compute to a place in GOT<br>
(e.g. G+A, G+GOT+A-P), but R_X86_64_GOTOFF64 (S+A-GOT) is different.<br>
"GOT" refers to the address of _GLOBAL_OFFSET_TABLE_.<br>
<br>
The large code model needs the GOT base ("GOT" in x86-64 psABI:<br>
"Represents the address of the global offset table") as a fixed place<br>
in the text segment to<br>
compute the addresses of symbols. The GOT base is not used in the GOT<br>
indirection manner.<o:p></o:p></p>
</div>
</div>
</body>
</html>