[PATCH 0/2] ARC Moving to @pcl relocations
rep.dot.nop at gmail.com
Thu Jul 28 22:04:46 UTC 2016
On July 28, 2016 8:50:41 PM GMT+02:00, Vineet Gupta <Vineet.Gupta1 at synopsys.com> wrote:
>On 07/28/2016 11:20 AM, Andrew Burgess wrote:
>> 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
>> 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
>> fact that the arithmetic construct that was previously used to
>> synthesise an @pcl like behaviour, does not work on recent versions
>> 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.
>Right - the idea at the time was @pcl was added to tools for TLS/NPTL
>thus uClibc NPTL loosely implied that your tools will have that support
>- but this
>was not the ideal choice I agree.
>> 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
>> the older versions of binutils in favour of the new @pcl relocation
>> type. This feels the cleanest solution, but I don't know how
>> the uClibc(-ng) community feels about maintaining compatibility for
>> older versions of the tools.
>So this was reported recently by Waldemar's build service too.
>And we have an exact same patch floated internally which Vlad sent out
>> Given that I anticipated push back against the first patch I took a
>> look at how I might maintain compatibility.
>Not really - while indeed 1/2 opens up a non-compatibilty window, there
>likelihood people will mix-n-match different baselines of uclibc and
>Vlad's patch does exactly that.
>> 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
>> based on the specific toolchain feature being supported or not, which
>> can then be used to conditionalise the code.
>Indeed your 2/2 seems to be the most "past-proof" code change. So I
>would think it
>is indeed better and is something I should have done in the first
>@Alexey, @Vlad what say you ?
uClibc traditionally supports the current stable release of binutils, which would make it patch #1 I think.
>> Would you consider merging one of these patches?
More information about the uClibc