Является ли разборка, показанная Visual studio, на самом деле сборкой?

Question

Иногда, когда я отлаживаю с помощью Visual Studio, я получаю эту опцию, no source code available, show disassembly , которое при нажатии показывает что-то вроде этого

0000001f  test        eax,eax 
00000021  je          0000000000000028 
00000023  call        FFFFFFFFF779C1D0 
00000028  cmp         qword ptr [rsp+48h],0 

Этот язык ассемблера специфичен для процессора? Если да, разработчики обычно используют это для отладки? Единственный язык ассемблера, который я выучил, был для 8085, который я больше не помню.

Answer 1

Да, это сборка.

0000001f  test        eax,eax 
00000021  je          0000000000000028 

test eax,eax проверяет, равен ли регистр eax нулю.
В этом случае он переходит на адрес 0x28. (je прыжок равен), пропуская следующий звонок. Если он не равен нулю, он не пропускает следующий вызов.
Независимо от этого он затем продолжается в 00000028 cmp qword ptr [rsp+48h],0

Все это кем-то, кто не использовал сборку i386 в течение 15 лет и кому приходилось гуглить на подобные хиты.

(Это мой вежливый способ сказать: «Пожалуйста, сделайте небольшое исследование, прежде чем спрашивать»).

Этот язык ассемблера специфичен для процессора?

Сборка зависит от диапазона / семейства процессоров.

Например, этот будет работать на AMD Opteron, AMD K6, K7, Intel Celeron, Intel Core, ... (все i386-иш код)

В то время как такие вещи будут работать на 6502, 6510 и подобных:
сеи
lda # $ 0d
Sta $ 0314
lda # $ c0
Sta $ 0315
кли
ртс

Если да, разработчики обычно используют это для отладки?

Я полагаю, что большинство не делают. Я предполагаю, что средний разработчик даже не знает, что такое сборка или машинный код. Он также не имеет ни малейшего представления об адресных шинах, шинах данных, строках кэша, архитектуре памяти или чем-то «глубоком».

Однако некоторые из нас делают.

Единственный язык ассемблера, который я выучил, был для 8085, который я больше не помню.

Это было предшественником кода, который вы использовали в примере.

Answer 2

Да, это фактическая разборка и она зависит от используемого процессора. В этом случае регистры "eax" указывают архитектуру микропроцессора x86.

И нет, разработчики обычно не используют это для отладки, вместо этого они используют исходный код (который, по-видимому, отсутствует по какой-то причине). Но он используется для поиска эксплойтов в коде, ошибок в компиляторе и т.д.

Answer 3

Да, этот язык ассемблера выглядит специфично для процессоров x64 . Используя Visual Studio, поскольку он работает только в Windows, вы, скорее всего, столкнетесь только с архитектурой Intel (хотя ARM также распространен в Linux). Однако есть некоторые инструкции, которые являются общими для многих архитектур (например, mov , add и другие - test is tst in ARM).

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

Хотя вы можете отлаживать в Assembly, обычно это делается на языке, на котором строится проект (например, C или C++).

Answer 4

,NEt-код компилируется в промежуточный язык ассемблера MSIL или CIL. Этот ассемблер не специфичен для ЦП, как традиционные языки ассемблера, и JIT (Just in Time) компилируется в нативную сборку во время выполнения виртуальной машиной .Net Frameworks, во многом как Java. MSIL будет работать на любой архитектуре процессора, для которой существует версия .Net Framework.

Вот введение в IL http://www.codeproject.com/Articles/3778/Introduction-to-IL-Assembly-Language

Большинство современных разработчиков не используют сборку, но если вы работаете с сборками с закрытым исходным кодом, посмотреть на IL - это все, что вы можете сделать. это может также помочь вам немного оптимизировать ваш код, если вы хорошо его знаете, но только у 1 из 20 или около того .Net-разработчиков когда-либо будет причина использовать его явно.