Mathieu Lacage <mathieu.lacage@xxxxxxxxx> writes:
> 1) is this (which tls model to use by default) the gist of the
> difference between -fpie and -fpic ? Are there other subtle
> differences between the two ?
They are also different in whether calls to locally defined functions go
through the PLT.
> 2) is there a way to make -fpie still use a dynamic tls model (short
> of hacking the code to add a tls_model("global-dynamic") attribute to
> my __thread variable declaration ?
There doesn't seem to be. It seems that -ftls-model can only be used to
decrease the TLS model of a variable, not to increase it. I'm not sure
why that is.
> [mathieu@mathieu-laptop test]$ gcc -fpie -pie ./test.c -o test
> /usr/bin/ld: /tmp/ccsIE4YR.o: relocation R_X86_64_TPOFF32 against
> `g_a' can not be used when making a shared object; recompile with
> -fPIC
> /tmp/ccsIE4YR.o: could not read symbols: Bad value
> collect2: ld returned 1 exit status
This seems like a bug in the linker. It seems that it should be
possible to fully resolve TPOFF32 at link time with -pie.
> [mathieu@mathieu-laptop test]$ gcc -fpie ./test.c -o test
> [mathieu@mathieu-laptop test]$ readelf -h ./test |grep Type
> Type: EXEC (Executable file)
> [mathieu@mathieu-laptop test]$ gcc -pie -fpic ./test.c -o test
> [mathieu@mathieu-laptop test]$ readelf -h ./test |grep Type
> Type: DYN (Shared object file)
>
> Which brings me to more questions:
> 1) why does "gcc -fpie -pie" fail to work ? Is this not the
> recommended way to use -fpie and -pie ? Could it be that -fpie is
> using the static tls model when it should not ?
Per above, I think it's a linker bug.
> 2) is "gcc -fpic -pie" expected to do anything sensible ? (as it
> appears to be doing)
In practice this will work, just as you can compile with -fpic and link
the resulting object into an executable. I don't think you should count
on this always working.
> 3) is "gcc -fpie" really unsupported ?
It's supported, though I don't know how much testing it gets.
Ian
