thr3ads.net - llvm dev - [llvm-dev] Relocations used for PPC32 in non-PIC mode [Oct 2017]

If this information is useful, please help other people find it:
Share via:

vit9696 via llvm-dev

2017-Oct-04 16:03 UTC

[llvm-dev] Relocations used for PPC32 in non-PIC mode

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: https://reviews.llvm.org/rL213427#C65598OL3360. 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 https://reviews.llvm.org/rL273499#C65598OL4294 and
https://reviews.llvm.org/rL273595#C65598OL4316. 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171004/a23f3dbd/attachment.sig>

Hal Finkel via llvm-dev

2017-Oct-04 16:28 UTC

head link

[llvm-dev] Relocations used for PPC32 in non-PIC mode

Hi, Vit,

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.

  -Hal

On 10/04/2017 11:03 AM, vit9696 via llvm-dev wrote:> 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: https://reviews.llvm.org/rL213427#C65598OL3360. 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 https://reviews.llvm.org/rL273499#C65598OL4294 and
https://reviews.llvm.org/rL273595#C65598OL4316. 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
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171004/f32363c3/attachment.html>

vit9696 via llvm-dev

2017-Oct-04 17:04 UTC

head link

[llvm-dev] Relocations used for PPC32 in non-PIC mode

Hal,

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.

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:

$ gcc -c t.c -o t.o
$ gcc -c s.c -o s.o
$ ld.lld t.o s.o -o t

vs

$ gcc -c -fpic t.c -o t.o
$ gcc -c -fpic s.c -o s.o
$ ld.lld t.o s.o -o t
error: t.c:(function _start): unrecognized reloc 18

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.

Vit
> 4 окт. 2017 г., в 19:28, Hal Finkel <hfinkel at anl.gov> написал(а):
> 
> Hi, Vit,
> 
> 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.
> 
>  -Hal
> On 10/04/2017 11:03 AM, vit9696 via llvm-dev wrote:
>> 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: https://reviews.llvm.org/rL213427#C65598OL3360
<https://reviews.llvm.org/rL213427#C65598OL3360>. 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 https://reviews.llvm.org/rL273499#C65598OL4294
<https://reviews.llvm.org/rL273499#C65598OL4294> and
https://reviews.llvm.org/rL273595#C65598OL4316
<https://reviews.llvm.org/rL273595#C65598OL4316>. 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
>> 
>> 
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 
> --
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171004/da964c94/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171004/da964c94/attachment.sig>

Reasonably Related Threads

Search for more maybe matching threads

llvm dev - Oct 2017 - Relocations used for PPC32 in non-PIC mode

[llvm-dev] Relocations used for PPC32 in non-PIC mode

[llvm-dev] Relocations used for PPC32 in non-PIC mode

[llvm-dev] Relocations used for PPC32 in non-PIC mode

Reasonably Related Threads