Re: [PATCH][ARM] Fix PR89222

2019-03-05 Thread Ramana Radhakrishnan
On 05/03/2019 12:33, Wilco Dijkstra wrote: ping From: Wilco Dijkstra Sent: 13 February 2019 12:23 To: Ramana Radhakrishnan Cc: GCC Patches; nd; Olivier Hainque Subject: Re: [PATCH][ARM] Fix PR89222 Hi Ramana, ARMv5te bootstrap OK, regression tests pass. OK for commit? Interesting

Re: [PATCH][ARM] Fix PR89222

2019-03-05 Thread Wilco Dijkstra
ping From: Wilco Dijkstra Sent: 13 February 2019 12:23 To: Ramana Radhakrishnan Cc: GCC Patches; nd; Olivier Hainque Subject: Re: [PATCH][ARM] Fix PR89222   Hi Ramana, >> ARMv5te bootstrap OK, regression tests pass. OK for commit? > > Interesting bug. armv5te-linux bootstr

Re: [PATCH][ARM] Fix PR89222

2019-02-13 Thread Wilco Dijkstra
Hi Ramana, >> ARMv5te bootstrap OK, regression tests pass. OK for commit? > > Interesting bug. armv5te-linux bootstrap ? Can you share your --target > and --with-arch flags ? --target/host/build=arm-linux-gnueabi --with-arch=armv5te --with-mode=arm >> +  if (GET_CODE (base) == SYMBOL_REF) > > I

Re: [PATCH][ARM] Fix PR89222

2019-02-13 Thread Olivier Hainque
> On 11 Feb 2019, at 22:32, Ramana Radhakrishnan > wrote: > Can Olivier or someone who cares about vxworks also give this a quick > sanity run for the alternate code path once we resolve some of the > review questions here ? Don't we also need to worry about > -mslow-flash-data where we get r

Re: [PATCH][ARM] Fix PR89222

2019-02-12 Thread Wilco Dijkstra
Hi Alexander, > It seems odd to me that the spec requires '(S+A) | T' instead of the (imho > more intuitive) '(S|T) + A', but apart from the missing diagnostic from the > linkers, it seems they do as they must and GCC was at fault. Doing (S+A) | T means bit zero always correctly encodes the Thumb

Re: [PATCH][ARM] Fix PR89222

2019-02-11 Thread Ramana Radhakrishnan
On Mon, Feb 11, 2019 at 5:35 PM Wilco Dijkstra wrote: > > The GCC optimizer can generate symbols with non-zero offset from simple > if-statements. Bit zero is used for the Arm/Thumb state bit, so relocations > with offsets fail if it changes bit zero and the relocation forces bit zero > to true.

Re: [PATCH][ARM] Fix PR89222

2019-02-11 Thread Alexander Monakov
On Mon, 11 Feb 2019, Wilco Dijkstra wrote: > > With Gold linker this is handled correctly.  So it looks to me like a > > bug in BFD linker, where it ignores any addend (not just +1/-1) when > > resolving a relocation against a Thumb function. > > If the Gold linker doesn't fail that means Gold has

Re: [PATCH][ARM] Fix PR89222

2019-02-11 Thread Wilco Dijkstra
Hi Alexander, > Just to be sure the issue is analyzed properly: if it's certain that this > usage > is not allowed, shouldn't the linker produce a diagnostic instead of silently > concealing the issue? The ABI doesn't require this but yes a linker could report a warning if the addend of a functi

Re: [PATCH][ARM] Fix PR89222

2019-02-11 Thread Alexander Monakov
On Mon, 11 Feb 2019, Wilco Dijkstra wrote: > The GCC optimizer can generate symbols with non-zero offset from simple > if-statements. Bit zero is used for the Arm/Thumb state bit, so relocations > with offsets fail if it changes bit zero and the relocation forces bit zero > to true. The fix is to

[PATCH][ARM] Fix PR89222

2019-02-11 Thread Wilco Dijkstra
The GCC optimizer can generate symbols with non-zero offset from simple if-statements. Bit zero is used for the Arm/Thumb state bit, so relocations with offsets fail if it changes bit zero and the relocation forces bit zero to true. The fix is to disable offsets on function pointer symbols. ARM