(Just for the record to avoid misleading)
I think the .eqv should fully work, but need to correct the reason for why.
It is not because it turned the new symbol into non-function type, but
because .eqv
is expect to always evaulate the snapshot value of the equaled
expression at each
place the new symbol is used, you don't know it's final value and the
associated
section, therefore it is associated with undefined section until the
final stage of
assembling. So, when doing ADR instruction assembling, at that stage,
the new
symbol is still without definition section assigned, therefore is able
to skip the LSB
setting which only happens for thumb function symbol with defined section.
binutils-gdb/gas/config/tc-arm.c: do_t_adr
...
&& S_IS_DEFINED (inst.reloc.exp.X_add_symbol)
&& THUMB_IS_FUNC (inst.reloc.exp.X_add_symbol))
inst.reloc.exp.X_add_number += 1;
Use .equ, the magic disappear.
Regards,
Jiong
On 04/08/17 14:58, Jiong Wang wrote:
Change
"adreq lr,X(ff_h264_idct_add_neon) +CONFIG_THUMB"
Into:
.eqv ff_h264_idct_add_neon_without_func_type, X(ff_h264_idct_add_neon)
adreq lr,ff_h264_idct_add_neon_without_func_type +CONFIG_THUMB
might be a solution. The idea is we use .eqv to remove the function
attribute, so the assembler won't set LSB in any case.
On 04/08/17 12:39, Jiong Wang wrote:
Hi,
This issue is caused by a recent change in ARM assembler included
since Binutils 2.29.
The details of that change can be found at
https://sourceware.org/bugzilla/show_bug.cgi?id=21458
The semantics of ADR has changed. In general, the address
generated by ADR will guarantee the LSB be set if it's a thumb
function address.
I noticed h264idct_neon.S is using something like:
adreq lr,X(ff_h264_idct_add_neon) +CONFIG_THUMB
As ADR now will set the LSB automatically, you don't need
CONFIG_THUMB any more.
I think h264idct_neon.S needs to be updated, and the modification
should make sure it works with both old Binutils and the new one.
Regards,
Jiong
