[Lldb-commits] [PATCH] D19480: Fix ARM attribute parsing for Android after rL267291

[Stephen Hines via lldb-commits]

srhines added a comment.

In http://reviews.llvm.org/D19480#410641, @rengolin wrote:

> In http://reviews.llvm.org/D19480#410620, @tberghammer wrote:
>
> > Both executables and shared libraries are containing ARM Attributes what contains the information about soft-float vs hard-float. I am not sure how accurate it is as in theory you can link together an object file compiled with soft float with a one compiled with hard float but most likely we can trust it to be good enough.
>
>
> That's only true if one doesn't depend on the other, and only if you can guarantee that hard-float library functions will only be called using AAPCS_VFP and soft-float library functions will only be called with AAPCS.
>
> This is not the kind of guarantee one can do easily. Nor it is recommended that one does so. If Android applications can guarantee that by having two different ABIs for Android specific and user specific, this could work in theory.
>
> > The problem is that currently this information is not stored in the llvm::Triple so if the Environment part of the Triple is set to Android then the information is lost. I can try to recover the data from the architecture flags but I am not convinced that it is always possible and considering that the same executable can contain soft-float and hard-float code on Android we have to treat them as compatible architectures at some point.
>
>
> The information is not lost, because "Android EABI" is always soft-float, and by definition, you should not be linking hard-float objects with soft-float ones.
>
> Can you elaborate which case you can reach that improbably scenario?


This happens because there is a broken mode (supported by an older NDK) that allowed for Hard FP calling conventions to be mixed with Soft FP in a hybrid mode. Everything in the user's application would get to use Hard FP, while any calls to bionic (libc/libm), or platform native libraries would use Soft FP. This wasn't really well tested, nor is it something that I think we should be promoting. Does this patch only affect debugging? Could we hold off on this until a long term decision is made about supporting mixed hard/soft FP calling conventions simultaneously?

> cheers,

> --renato





http://reviews.llvm.org/D19480