Page MenuHomePhabricator

[LLD][ARM] Accept first SHT_ARM_ATTRIBUTES section

Authored by peter.smith on Dec 13 2016, 10:14 AM.



The eglibc C library, as used by Ubuntu 14.04, and similar Debian bases systems, requires the presence of an SHT_ARM_ATTRIBUTES section in for the purposes of checking hard/soft float compatibility when dlopen() is used. Unfortunately when the section is not present dlopen() fails with a generic could not find file message.

This change makes lld keep the first .ARM.attributes section that it encounters and propagates it to the output. This is not a complete SHT_ARM_ATTRIBUTES implementation, that would involve reading the contents of the section and joining each individual attribute. It should suffice for a homogenous build all libraries and executables on the same system with a compatible set of command line options.

My understanding is that later versions of glibc, which eglibc was merged into a couple of years ago do not have this check. However Trusty (14.04) and Debian is common on the consumer devices that people do ARM development on such as Raspberry Pis and Chromebooks so I think it is worth making this change to get dlopen() to work.

Diff Detail


Event Timeline

peter.smith retitled this revision from to [LLD][ARM] Accept first SHT_ARM_ATTRIBUTES section.
peter.smith updated this object.
peter.smith added reviewers: ruiu, rafael.
peter.smith added a subscriber: llvm-commits.
ruiu accepted this revision.Dec 13 2016, 10:38 AM
ruiu edited edge metadata.


344 ↗(On Diff #81248)

So you are using In<ELFT>::ARMAttributes as a boolean flag rather than an InputSection object in the sense that the variable is used only to check if we have already created a section instance for ARMAttribute. It doesn't feel like the right approach to me, but honestly I cannot think of a better way. So, LGTM, but do you think any other ways?

This revision is now accepted and ready to land.Dec 13 2016, 10:38 AM

Thanks for the review. My first idea was to put a flag in Config, but that didn't seem right either. If we were wanting to merge the build attributes sections we'd probably want to do so via a SyntheticSection so I thought it would be easier to start that way.

I'll commit tomorrow as I need to leave the office in a few minutes.

This revision was automatically updated to reflect the committed changes.