<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hal,</div><div class=""><br class=""></div><div class="">Alright, I submitted it: <a href="https://reviews.llvm.org/D38554" class="">https://reviews.llvm.org/D38554</a>.</div><div class="">I also added a test case that will fail unless the patch is applied to quickly illustrate the problem.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Vit</div><br class=""><div><blockquote type="cite" class=""><div class="">4 окт. 2017 г., в 20:24, Hal Finkel <<a href="mailto:hfinkel@anl.gov" class="">hfinkel@anl.gov</a>> написал(а):</div><br class="Apple-interchange-newline"><div class="">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type" class="">
<div bgcolor="#FFFFFF" text="#000000" class=""><p class="">Hi, Vit,</p><p class="">I believe that we may use PIC by default, but it should be
possible to disable it. Please feel free to submit a patch for
review.</p>
Thanks,<br class="">
Hal<br class="">
<br class="">
<div class="moz-cite-prefix">On 10/04/2017 12:04 PM, vit9696 via
llvm-dev wrote:<br class="">
</div>
<blockquote cite="mid:5CE1600A-6C48-43C0-A1C5-D021A2F0C074@avp.su" type="cite" class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<div class="">
<div class="">Hal,</div>
<div class=""><br class="">
</div>
<div class="">I very well understand that LDD may not be in a
good state for PPC32, and it would definitely need some
improvements sooner or later. In fact I even submitted a patch
adding a relocation to ldd just a few hours ago.</div>
<div class=""><br class="">
</div>
<div class="">However, this particular case is not related to
LDD, it is a design issue and furthermore a regression in LLVM
itself. I checked gcc, and neither does it try to use PLT and
R_PPC_PLTREL24 relocations unless I pass -fpic:</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">$ gcc -c t.c -o t.o</div>
<div class="">$ gcc -c s.c -o s.o</div>
<div class="">$ ld.lld t.o s.o -o t</div>
<div class=""><br class="">
</div>
<div class="">vs</div>
<div class=""><br class="">
</div>
<div class="">$ gcc -c -fpic t.c -o t.o</div>
<div class="">$ gcc -c -fpic s.c -o s.o</div>
<div class="">$ ld.lld t.o s.o -o t</div>
<div class="">error: t.c:(function _start): unrecognized reloc
18</div>
</div>
<div class=""><br class="">
</div>
<div class="">The behaviour is simply incorrect, and in fact it
may even be dangerous for embedded software with custom
bootloaders that is migrating to clang compilers. It is not
(just) for LDD we should fix this, but also for compatibility
with gcc, and because currently -fno-pic switch simply does
not affect this part, making its undesired behaviour
unconditionally enforced.</div>
<div class=""><br class="">
</div>
<div class="">Vit</div>
</div>
<br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">4 окт. 2017 г., в 19:28, Hal Finkel <<a moz-do-not-send="true" href="mailto:hfinkel@anl.gov" class="">hfinkel@anl.gov</a>> написал(а):</div>
<br class="Apple-interchange-newline">
<div class="">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type" class="">
<div bgcolor="#FFFFFF" text="#000000" class=""><p class="">Hi, Vit,</p><p class="">I'm not under the impression that ppc support
in lld is anywhere near ready for use. I had it linking
hello world on ppc64 some time ago, and it's not clear
that ppc is even that far. I'd not adjust anything in
LLVM based on ppc support in lld right now.</p><p class=""> -Hal<br class="">
</p>
<div class="moz-cite-prefix">On 10/04/2017 11:03 AM,
vit9696 via llvm-dev wrote:<br class="">
</div>
<blockquote cite="mid:A12939A0-657F-4382-9E03-0A40E677F459@avp.su" type="cite" class="">
<pre class="" wrap="">Hello,
I am currently facing an issue at linking stage when compiling basic C code for an embedded PPC32 platform and linking with LLD. For external symbol linkage LLVM appears to use PLT which results in generating a R_PPC_PLTREL24 relocation, that is not support by LDD. Therefore even such a basic example cannot be built:
/* s.c */
int f() { return 0; }
/* t.c */
int f();
int _start() { return f(); }
$ clang -c -target ppc32-gnu-linux-eabi t.c -o t.o
$ clang -c -target ppc32-gnu-linux-eabi s.c -o s.o
$ ld.lld t.o s.o -o t
ld.lld: error: t.c:(function _start): unrecognized reloc 18
When I tried ld.bfd the objects linked fine, so I initially thought that it was a lld issue. Yet, after I checked the source code, I started to feel that PLT use on PPC32 is not even desired, and it is likely just an overlooked regression. If you check the original code, PLT was only meant to be used with PIC code: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://reviews.llvm.org/rL213427#C65598OL3360">https://reviews.llvm.org/rL213427#C65598OL3360</a>. Note, that there are two places covering the PPCII::MO_PLT_OR_STUB assignment, which are both guarded with getRelocationModel check.
Now let's look at <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://reviews.llvm.org/rL273499#C65598OL4294">https://reviews.llvm.org/rL273499#C65598OL4294</a> and <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://reviews.llvm.org/rL273595#C65598OL4316">https://reviews.llvm.org/rL273595#C65598OL4316</a>. For some unknown reason these two commits silently removed -fno-pic handling, and effectively enforced PLT use. As a result they broke the compatibility with linkers not implementing PLT-relative relocations.
While it might be good for LLD to support R_PPC_PLTREL24, in my opinion there still is no reason for LLVM to emit this in non-PIC mode. If my understanding is correct, I can submit a patch that will replace
bool UsePlt = !Local && Subtarget.isTargetELF() && !isPPC64;
with
bool UsePlt = !Local && Subtarget.isTargetELF() && !isPPC64 &&
DAG.getTarget().getRelocationModel() == Reloc::PIC_;
Vit
</pre>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre class="" wrap="">_______________________________________________
LLVM Developers mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br class="">
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</div>
</div>
</blockquote>
</div>
<br class="">
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre wrap="" class="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br class="">
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</div>
</div></blockquote></div><br class=""></body></html>