(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.


On 04/08/17 14:58, Jiong Wang wrote:


  "adreq lr,X(ff_h264_idct_add_neon) +CONFIG_THUMB"


.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:

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.


pkg-multimedia-maintainers mailing list

Reply via email to