Page MenuHomePhabricator

[ELF][ARM] Process ARM build attributes of dynamic libraries.

Authored by ikudrin on Dec 18 2018, 3:19 AM.



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.

Diff Detail

rLLD LLVM Linker

Event Timeline

ikudrin created this revision.Dec 18 2018, 3:19 AM
grimar added inline comments.Dec 18 2018, 3:58 AM

We have Config->IsLE.


Can we have ARMAttributesSec when Config->EMachine != EM_ARM?
Seems it can be just if (this->ARMAttributesSec)

I have several reservations about doing this:

  • BuildAttributes are only defined for relocatable object files, the ABI does not require or prevent them from appearing in Shared Objects or Executables therefore nothing should rely on their presence.
  • Can it be guaranteed that the shared object we link against will have the same attributes as the shared object at run time?
  • Should the attributes of the shared object be aggregated with the attributes from the relocatable object?

This is all outside of the specification 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 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.

ikudrin abandoned this revision.Dec 18 2018, 6:19 AM

Thanks again, Peter!