[llvm-dev] How does -fPIE get passed from clang to llc when run on a .ll file?

[Phil Tomson via llvm-dev]

If I create an llvm IR file (.ll) using clang like this:

  clang -v -emit-llvm -fPIC -O0 -S global_dat.c -o global_dat_x86_pic.ll



And then take a look at the resulting .ll file, I see near the bottom:

  !0 = !{i32 1, !"PIC Level", i32 2}



Now if I do the same, but specify -fPIE:

  clang -v -emit-llvm -fPIE -O0 -S global_dat.c -o global_dat_x86_pie.ll



And then look at the resulting global_dat_x86_pie.ll file, I see it is identical to the one where I specified -fPIC (global_dat_x86_pic.ll). There's no indication of the PIE level in the .ll file.



However, I can see (based on the verbose output) that the PIE Level should be 2:

   "clang-3.6" -cc1 -triple xstg--linux-elf -emit-llvm -disable-free -main-file-name global_dat.c -mrelocation-model pic -pic-level 2 -pie-level 2 ...



So if I were to pass this .ll file (global_dat_x86_pie.ll) to llc how would llc know that the PIE Level is 2? Is this an oversight, bug, or expetcted behaviour with a different workaround?





[Tim Northover via llvm-dev]

On 6 November 2015 at 10:32, Phil Tomson via llvm-dev

<llvm...@lists.llvm.org> wrote:
> So if I were to pass this .ll file (global_dat_x86_pie.ll) to llc how would
> llc know that the PIE Level is 2? Is this an oversight, bug, or expetcted
> behaviour with a different workaround?

It looks like it's the "-enable-pie" command line option, which gets
hooked up to TargetOptions::PositionIndependentExecutable if you're
doing it programmatically. I'm not sure of the history behind why
they're different though, I'm afraid.

Tim.
_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

[Phil Tomson via llvm-dev]

On Fri, Nov 6, 2015 at 10:46 AM, Tim Northover <t.p.no...@gmail.com> wrote:

On 6 November 2015 at 10:32, Phil Tomson via llvm-dev
<llvm...@lists.llvm.org> wrote:
> So if I were to pass this .ll file (global_dat_x86_pie.ll) to llc how would
> llc know that the PIE Level is 2? Is this an oversight, bug, or expetcted
> behaviour with a different workaround?

It looks like it's the "-enable-pie" command line option, which gets
hooked up to TargetOptions::PositionIndependentExecutable if you're
doing it programmatically. I'm not sure of the history behind why
they're different though, I'm afraid.

With 3.6 I get an unused argument warning with -enable-pie:

$ clang -v -emit-llvm -enable-pie -O0 -S global_dat.c -o global_dat_x86_pie.ll

clang: warning: argument unused during compilation: '-e nable-pie'

 

[Tim Northover via llvm-dev]

On 6 November 2015 at 11:00, Phil Tomson <phil.a...@gmail.com> wrote:
> With 3.6 I get an unused argument warning with -enable-pie:
>
> $ clang -v -emit-llvm -enable-pie -O0 -S global_dat.c -o
> global_dat_x86_pie.ll

Yes, it's an llc option not a Clang option. It actually looks like
Clang doesn't forward it to LLVM at all (almost certainly a bug, if
so). But that's probably OK because the only place LLVM actually uses
it at all is to determine what kind of TLS model to use
(TargetMachine.cpp), which linkers can mostly relax anyway.

It does seem to get passed onto the linker by Clang though.

Cheers.

[Phil Tomson via llvm-dev]

On Fri, Nov 6, 2015 at 11:10 AM, Tim Northover <t.p.no...@gmail.com> wrote:

On 6 November 2015 at 11:00, Phil Tomson <phil.a...@gmail.com> wrote:
> With 3.6 I get an unused argument warning with -enable-pie:
>
> $ clang -v -emit-llvm -enable-pie -O0 -S global_dat.c -o
> global_dat_x86_pie.ll

Yes, it's an llc option not a Clang option. It actually looks like
Clang doesn't forward it to LLVM at all (almost certainly a bug, if
so). But that's probably OK because the only place LLVM actually uses
it at all is to determine what kind of TLS model to use
(TargetMachine.cpp), which linkers can mostly relax anyway.

In my case I'm actually working on a backend for a new architecture and need this to show up in LLVM because certain pseudo ops need to be expanded in a certain way if we're using PIE (vs. just a default static link). So are these options accessible in the Target-specific code? 

It does seem to get passed onto the linker by Clang though.

Not sure how that can work.

Cheers.

Tim.

[Akira Hatanaka via llvm-dev]

If the target platform is linux and -fPIE is on the command line, clang sets TargetOptions::PositionIndependentExecutable in EmitAssemblyHelper::CreateTargetrMachine.

[Eric Christopher via llvm-dev]

We should probably make this a nomerge IR option.

[Tim Northover via llvm-dev]

On 6 November 2015 at 11:23, Akira Hatanaka <ahat...@gmail.com> wrote:
> If the target platform is linux and -fPIE is on the command line, clang sets
> TargetOptions::PositionIndependentExecutable in
> EmitAssemblyHelper::CreateTargetrMachine.

I was looking in a hurry at the time, but to me it seemed that was
under the "clang -cc1" execution and there was nothing on that
command-line to indicate PIE. I'd swear I even set a breakpoint there
and it got set wrongly. Maybe only the platforms that care have wired
it up or something.

[Tim Northover via llvm-dev]

> I was looking in a hurry at the time, but to me it seemed that was
> under the "clang -cc1" execution and there was nothing on that
> command-line to indicate PIE. I'd swear I even set a breakpoint there
> and it got set wrongly. Maybe only the platforms that care have wired
> it up or something.

Ah no, my mistake. Probably a stale "-cc1" invocation. Too much of a
hurry, it seems.