Why do we emit ABI_PCS_RW_data, ABI_PCS_RW_data and ABI_PCS_GOT_use?

[Peter Smith via llvm-commits]

Hello Rafael,

You probably won't find too many uses outside of ARM's proprietary
compiler armcc and its llvm based replacement armclang which does
output these build attributes with certain options [*]. They are
useful for a bare-metal linker to diagnose incompatible objects, and
in some cases such as ARM's proprietary linker armlink, they can be
used to select compatible binary only system libraries. It is true
that they will have limited use in a linux environment but they are
much more useful in an embedded environment.

Going through each one of the attributes in turn:
Tag_ABI_PCS_RW_DATA
      0  RW static data was permitted to be addressed absolutely
      1  RW static data was only permitted to be addressed PC-relative
      2  RW static data was only permitted to be addressed SB-relative
      3  The user did not permit this entity to use RW static data

0 is the default with absolute addressing of RW data allowed
1 Maps to the armcc --apcs=/ropi and -fPIC in clang and gcc
2 Maps to the armcc --apcs=/rwpi option. There is no direct equivalent
in gcc (-msingle-pic-base -mpic-register=r9
-mno-pic-data-is-text-relative in arm-eabi-gcc is close)
3 is a theoretical no RW allowed option. In at least some versions of
Symbian OS writeable static data was not allowed in DLLs so this
option would permit a linker to do at least some checking. I'm not
aware of this being used in practice.

 Tag_ABI_PCS_RO_data, (=16), uleb128
      0  RO static data was permitted to be addressed absolutely
      1  RO static data was only permitted to be addressed PC-relative
      2  The user did not permit this entity to use RO static data
0 is the default with absolute addressing of RO data allowed
1 Maps to the armcc --apcs=/ropi and -fPIC in clang and gcc
2 is a theoretical no static RO data option. I don’t believe this has
ever been used by a compiler.

Tag_ABI_PCS_GOT_use, (=17), uleb128
      0  The user did not permit this entity to import static data
      1  The user permitted this entity to address imported data directly
      2  The user permitted this entity to address imported data
indirectly (e.g. via a GOT)

0 is representative of a bare metal image that does not support
dynamic linking and can import no static linker.
1 is kind of bare-metal dynamic linking, all relocations to imported
data are just passed on to a post-linker without building a GOT. In
embedded systems this can be an off-line dynamic linker that assembles
and relocates bare-metal modules, but the final output is just a
binary with no dynamic relocation.
2 is imported data is indirected through a GOT, like in Linux.

With these in mind the right values for -fPIE will depend on whether a
-fPIE allows any form of absolute addressing of static data. If the
answer is no then the right values are Tag_ABI_PCS_RW_DATA = 1,
Tag_ABI_PCS_RO_data = 1, Tag_ABI_PCS_GOT_use = 2.

If any absolute addressing of static data is allowed by -fPIE then
Tag_ABI_PCS_RW_DATA = 0, Tag_ABI_PCS_RO_data = 0. My understanding of
-fPIE is that absolute addressing is not allowed, but I haven't
checked for special cases.

In practice I don't think that there is a combination of build
attributes that can distinguish -fPIE from -fPIC, which would in
theory allow a linker to give an error message if an object compiled
-fPIE where used in a shared library.

Hope this helps

[*] http://lists.llvm.org/pipermail/llvm-dev/2015-December/093022.html

Peter

On 20 June 2016 at 22:35, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> I can't seem to find anything that actually uses it and gcc doesn't
> produce them.
>
> The attached patch changes llvm to not produce them.
>
> If we do need to produce them for some reason, what are the correct
> values for -fPIE?
>
> Cheers,
> Rafael