Почему инструкции ADR с прямой ссылкой собираются с четными смещениями в коде Thumb?

Вам не хватает этой строки из документации ARM для Псевдо-инструкция ADR:

Если вы используете ADR для генерации цели для инструкции BX или BLX, вы обязаны установить бит Thumb (бит 0) адреса, если цель содержит инструкции Thumb.

Инструкции ADR с прямым обращением используют 16-битную форму Thumb "ADD Rd, pc, #imm" инструкции ADD. Непосредственное значение этой инструкции находится в диапазоне 0-1020 и должно быть выровнено по словам (т. Е. Закодировано 8-битным полем и умножено на 4.) Используемое значение PC также имеет младшие два бита, установленные в 0, поэтому он не может генерировать нечетный адрес.

Принуждение ассемблера всегда использовать 32-битную инструкцию Thumb с ADR.W должно привести к тому, что он всегда будет генерировать нечетный адрес при использовании метки функции, но я не знаю, можете ли вы на это положиться. Вероятно, было бы лучше просто явно установить младший бит.

Возвращаясь к этому вопросу. Ошибка действительно такая простая:

  if (inst.relocs[0].exp.X_op == O_symbol
      && inst.relocs[0].exp.X_add_symbol != NULL
      && S_IS_DEFINED (inst.relocs[0].exp.X_add_symbol)
      && THUMB_IS_FUNC (inst.relocs[0].exp.X_add_symbol))
    inst.relocs[0].exp.X_add_number += 1;

в функции do_t_adr ().

S_IS_DEFINED проверяет, определен ли символ, при выполнении прямой ссылки в этот момент времени символ не определен, поэтому эта строка не проходит, он не добавляет один, что очень мешает чистоте, он должен ORR один , но что угодно. Для обратной ссылки обозначен символ, поэтому настройка выполняется. (Естественно, THUMB_IS_FUNC не будет работать без определенного символа)

ADR преобразуется в BFD_RELOC_ARM_THUMB_ADD. Что приводит нас сюда

case BFD_RELOC_ARM_THUMB_ADD:
  /* This is a complicated relocation, since we use it for all of
 the following immediate relocations:

    3bit ADD/SUB
    8bit ADD/SUB
    9bit ADD/SUB SP word-aligned
   10bit ADD PC/SP word-aligned

 The type of instruction being processed is encoded in the
 instruction field:

   0x8000  SUB
   0x00F0  Rd
   0x000F  Rs
  */

и внутри этого здесь

else if (rs == REG_PC || rs == REG_SP)
  {
    /* PR gas/18541.  If the addition is for a defined symbol
       within range of an ADR instruction then accept it.  */

И тот код, который происходит на более позднем проходе (после того, как символ был определен и может быть найден), не исправляет немедленное / смещение.

Я нахожу еще более тревожным / ошибочным то, что он не может справиться с этим без унифицированного .syntax.

.thumb
.thumb_func
zero:
    adr r0,zero

даже с унифицированным .syntax они не закончили внедрение ADR для T16. Просто поместите туда ошибку и объявите, что все готово. (Конечно, может быть реализовано, например, в T16 add rx, pc, # 0, sub rx, # offset.)

Даже если бы они исправили это, я бы избежал инструкции ADR. Но ясно, что они не удосужились завершить реализацию этой псевдо-инструкции.

Обратите внимание, что в режиме охраны у них есть такая же ошибка, когда проверка символа выполняется не в то время.

  if (support_interwork
      && inst.relocs[0].exp.X_op == O_symbol
      && inst.relocs[0].exp.X_add_symbol != NULL
      && S_IS_DEFINED (inst.relocs[0].exp.X_add_symbol)
      && THUMB_IS_FUNC (inst.relocs[0].exp.X_add_symbol))
    inst.relocs[0].exp.X_add_number |= 1;

Обратите внимание, что ORR не ДОБАВЛЯЕТ одного, лучшего / другого автора, но не совсем продумывал это решение.

Если я удалю проверки S_IS_DEFINED и THUMB_IS_FUNC

.arm
zero:
    adr r0,two
.thumb
.thumb_func
two:
    nop

идет от

00000000 <zero>:
   0:   e24f0004    sub r0, pc, #4

00000004 <two>:
   4:   46c0        nop         ; (mov r8, r8)
   6:   46c0        nop         ; (mov r8, r8)

to

00000000 <zero>:
   0:   e24f0003    sub r0, pc, #3

00000004 <two>:
   4:   46c0        nop         ; (mov r8, r8)
   6:   46c0        nop         ; (mov r8, r8)

так же

.syntax unified

.thumb
    adr r0,two
    nop
    nop
.thumb_func
two:
    nop

дает

00000000 <two-0x8>:
   0:   f20f 0005   addw    r0, pc, #5
   4:   46c0        nop         ; (mov r8, r8)
   6:   46c0        nop         ; (mov r8, r8)

00000008 <two>:
   8:   46c0        nop         ; (mov r8, r8)

Обратите внимание, что это можно было бы легко реализовать с помощью инструкций T16 (использует 4 байта, как и решение T32), но это, как уже упоминалось, еще одна ошибка:

.syntax unified
.cpu cortex-m0
.thumb
    adr r0,two
    nop
    nop
.thumb_func
two:
    nop

/path/so.s: Assembler messages:
/path/so.s:5: Error: invalid immediate for address calculation (value = 0x00000003)

(и эта ошибка находится в том же разделе кода, где есть указанная вами ошибка)

Было бы интересно посмотреть, что, во-первых, говорится в документации для других ассемблеров в отношении ADR и thumb, а во-вторых, если они действительно реализуют это в соответствии с этой документацией и / или выручают с ошибкой или предупреждением.