Why do we emit ABI_PCS_RW_data, ABI_PCS_RW_data and ABI_PCS_GOT_use?

Rafael Espíndola via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 21 05:47:48 PDT 2016


On 21 June 2016 at 05:35, Peter Smith <peter.smith at linaro.org> wrote:
> 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.

<sigh>
It is annoying that we have code to support use cases that are not
visible anywhere. In cases like this people not at ARM can only wonder
what is going on. The use of attributes for this also seems a
misfeature. The relocations encode how data is accessed, and the
linker can provide a more precise error on exactly what prevents a
given .o file from being used.

Like the constant pool case for aarch64, I think this should ideally
be a local patch for armclang.
</sigh>


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

And I don't think there should be. With -fPIE we can create code that
assumes a symbol is local. If that fails at link time, it is far
better for the linker to diagnose exactly why that .o file cannot go
in a .so.

> Hope this helps

Yes, I will make sure we produce the correct values for -fPIE.

Thanks,
Rafael


More information about the llvm-commits mailing list