Неизвестное значение двоеточия (:) в инструкции по сборке

Я использую дизассемблер (SmartDec: http://decompilation.info/) и многие инструкции в сгенерированная разборка выглядит примерно так:

mov rax, [rip + 0x32b5]:64

Я не знаком с :64 частью этой инструкции. Что это означает?

Другие примеры:

cmp [rcx + r8 * 0x8]:64, 0x0
mov eax, [rip + 0x592a]:32
jmp [rip + 0x6bad]:64

Этот дизассемблер не показывает соответствующий машинный код, поэтому я воспользовался шестнадцатеричным редактором и посмотрел адрес, по которому, по его словам, находилась эта инструкция:

1665:   mov rax, [rip + 0x19a4]:64

Вот что там было, 16 байт, в Little Endian:

54 00 00 49 89 E8 FF 15 DC 5F 00 00 E9 57 FF FF

person SeanRamey    schedule 30.12.2017    source источник
comment
SmartDec — дизассемблер, decompilation.info   -  person SeanRamey    schedule 30.12.2017
comment
Я не думаю, что у вас есть правильные шестнадцатеричные байты для этой инструкции. Я нигде не вижу a4 или 19 байт в машинном коде. Возможно, ваш дизассемблер на самом деле не имеет в виду RIP+, и на самом деле он означает, что абсолютный адрес 0x19a4 адресован относительно RIP. Но в любом случае 54 не является опкодом для mov. 49 89 ... – это REX.W=1 mov r/m64, r64 (хранилище), если только эти байты являются частью (а не началом) другой инструкции. Я бы рекомендовал использовать другой дизассемблер (например, objdump -drwC -Mintel) для сравнения в будущем.   -  person Peter Cordes    schedule 30.12.2017


Ответы (1)


Это размер операнда памяти, напечатанного по какой-либо причине. Я вывел его из примера на домашней странице SmartDec, который читается как movzx edx, [ecx]:16 Таким образом, это просто эквивалентно тому, что было бы movzx edx, word [ecx] в других ассемблере (или word ptr). Это полезно только в том случае, если размер нельзя вывести из другого операнда, как в этом случае movzx. SmartDec, кажется, показывает это каждый раз, например. для вашего примера в вопросе mov rax, [rip + 0x32b5]:64 ясно, что размер составляет 64 бита, поэтому это мало помогает.

person Jester    schedule 30.12.2017
comment
Большое спасибо! Интересно, почему они решили поступить именно так, а не так, как принято? - person SeanRamey; 30.12.2017
comment
@SeanRamey выглядит для меня кратчайшим путем (:16 против word ), и все еще хорошо читается для меня, также двоеточие часто используется вместе с подсчетом битов или манипулированием битами, так что это не совсем шокирует меня ... насколько я' Меня это беспокоит, я не возражаю против этой новой (для меня) нотации (в отличие от других трюков, которые я видел, например asmGo, я думаю, или что-то в этом роде). ... в любом случае, почему =› почему бы и нет? Никогда не было слишком строгого стандарта сборки x86, Intel поддерживает его в некоторой степени согласованным в документации, но его нельзя использовать для написания исходного кода как есть, и ассемблеры всегда продолжали определять недостающие части. - person Ped7g; 30.12.2017