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

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?

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.

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'

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.

Tim.

> 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.

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

We should probably make this a nomerge IR option.

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.

Cheers.

Tim.

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.

Tim.