`jz` к RIP-относительной ячейке памяти вызывает несоответствие операндов (GCC) - PullRequest
Новая
       14

`jz` к RIP-относительной ячейке памяти вызывает несоответствие операндов (GCC)

0 голосов
/ 20 января 2019 
.macro alloc_linked_list_item_rdi_rax
        movq $24, %rdi
        call malloc@PLT
        testq %rax, %rax
        leaq 0x1a(%rip), %r10
        jz *%r10  # <=
        movq $0xA, 0x0(%rax)  # void *data
        movq $0x0, 0x8(%rax)  # struct linked_list_item *prev
        movq $0x0, 0x10(%rax) # struct linked_list_item *next
.endm

Когда я пытаюсь собрать следующий макрос (с GCC на GNU / Linux Debian x86-64), ассемблер выдает ll.s:86: Error: operand type mismatch for 'jz', где ll.s:86 относится к этому макросу, в этом конкретном jz.

Для этого макроса я попытался использовать локальные метки для управления потоком управления, однако возникла ошибка, что у меня не может быть повторяющихся имен меток (так как я использовал макрос дважды в программе), и поэтому я повернулся к прыжок с расположением RIP (рассчитывается с использованием objdump и последующим подсчетом длины инструкций).

Данная сборка сработала, если бы я заменил jz на безусловный jmp, так как из-за этого я запутался, почему написанный мной код не работает.

Может ли кто-нибудь пролить свет?

1 Ответ

0 голосов
/ 20 января 2019

Набор команд x86 имеет только условные переходы с непосредственными операндами (которые описывают смещение относительно счетчика программы). Другие операнды нуждаются в безусловной инструкции перехода. Простой способ обойти это состоит в том, чтобы инвертировать смысл прыжка и перепрыгнуть через безусловную инструкцию перехода, как это: 

        jnz .Lalloc_linked_list_item_rdi_rax.\@
        jmp *%r10
.Lalloc_linked_list_item_rdi_rax.\@:

(Смешное имя ярлыка намеревается избежать столкновений с другими ярлыками.)

Если я правильно помню, некоторые старые ассемблеры делали это автоматически, но это стало менее полезным и фактически весьма запутанным, когда статическое предсказание ветвления поступало в ЦП, потому что оно скрывало то, как ЦП предсказывал ветвления. (Но большинство современных процессоров x86 больше не полагаются на статическое предсказание ветвлений, кажется, поэтому мы вернулись к тому, с чего начали.)

...