search for: global_dat_x86_pie

...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: "cl...

On Fri, Nov 6, 2015 at 10:46 AM, Tim Northover <t.p.northover at gmail.com> wrote: > On 6 November 2015 at 10:32, Phil Tomson via llvm-dev > <llvm-dev at 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::PositionIndepe...

...m Northover <t.p.northover at gmail.com> wrote: > On 6 November 2015 at 11:00, Phil Tomson <phil.a.tomson at 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 us...