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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
