This helps to detect incompatible settings between dynamic libraries and other input files.
Note that GOLD issues an error in that case, while LD ignores it.
However, I believe that it is better to be strict here.
I have several reservations about doing this:
This is all outside of the specification http://infocenter.arm.com/help/topic/com.arm.doc.ihi0045e/IHI0045E_ABI_addenda.pdf BuildAttributes are only defined for relocatable objects see (2.1.3 The scope of build attributes). Granted there is nothing stopping LLD defining its own behaviour on top of the specification but I think we should be very careful doing so. Given that we can't guarantee what we are linking against dynamically I'm definitely against updating the attributes of the ELF file based on Shared Objects, at least not without proposing a change to the ABI. There may be a case for a warning for certain specific clashes, but I don't think we should do this in the general case.
I'm out of the office till next year so I can't give many more comments on this. There is a mailing list for the Arm ABI firstname.lastname@example.org that you can ask further questions on what BuildAttributes should be used for.
Thank you for the explanation, Peter!
It seems like we definitely should not update the attributes based on Shared Objects, but what do you think about preventing linking against SOs with clashing attributes? Should we prevent that and issue an error (like GOLD does), or ignore it (like LD), or, maybe, just warn a user?
Unless we have evidence that many users are making the mistake of linking against incompatible shared objects, my personal preference is that it is better to follow ld.bfd and ignore. I think most toolchains and distributions make this mistake hard to do by accident.
If we do have evidence that this is a problem, or others feel strongly about it, then my personal preference is a warning. For example a function in a shared library might have uses hard-float in its BuildAttributes but no floating-point types in its interface so it is callable from both a hard-float and soft-float ABI executable. This is in theory true of relocatable objects as well but the interfaces to shared libraries tend to be narrower and more feasible to control.