[PATCH 0/2] ARC Moving to @pcl relocations
andrew.burgess at embecosm.com
Thu Jul 28 18:20:12 UTC 2016
This is a slightly odd series of 2 patches. The two patches are
actually alternative solutions to the same problem. I'm keen to see
one of these merged, but I don't know which method would be preferred.
This commit aims to address an issue that was introduced / mentioned
in commit 20554a78a9bba278c6b9cbbb4cfc5bde3772c56d (ARC:
Conditionalise certain relocations as provided by TLS tools only).
The problem is that not all historic versions of binutils have
supported the @pcl relocation type. This problem is compounded by the
fact that the arithmetic construct that was previously used to
synthesise an @pcl like behaviour, does not work on recent versions of
In the commit 20554a78a code was added that selects between the new
style @pcl relocations, and the old style arithmetic construct,
however, this selection is done based on whether the uClibc user has
configured with native threads or not.
Of course, a uClibc user could choose to use a modern version of
binutils AND configure without native thread support, in which case
uClibc will not compile.
I have two proposed solutions. In patch 1/2 I simply drop support for
the older versions of binutils in favour of the new @pcl relocation
type. This feels the cleanest solution, but I don't know how strongly
the uClibc(-ng) community feels about maintaining compatibility for
older versions of the tools.
Given that I anticipated push back against the first patch I took a
look at how I might maintain compatibility. It turns out to be pretty
easy, and that is patch 2/2. In this patch I drew inspiration from
similar examples in the Rules.mak file to check if the toolchain
supports @pcl relocations or not. With this done we have a new define
based on the specific toolchain feature being supported or not, which
can then be used to conditionalise the code.
Would you consider merging one of these patches?
More information about the uClibc