A desmontagem mostrada pelo Visual Studio é realmente montagem?

1

Às vezes, quando eu depurar usando o visual studio, eu recebo essa opção no source code available, show disassembly , que quando clicado mostra coisas como esta

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

Esta linguagem assembly é específica do processador? Se sim, os desenvolvedores geralmente usam isso para depuração? A única linguagem de montagem que aprendi foi em 8085, da qual não me lembro mais.

    
por developer747 01.08.2013 / 20:10

4 respostas

4

Sim, isso é montagem.

0000001f  test        eax,eax 
00000021  je          0000000000000028 

test eax,eax verifica se o registro eax é zero.
Se este for o caso, pule para o endereço 0x28. ( je é igual a pular), pulando a próxima chamada. Se não for zero, não pula a próxima chamada.
Independentemente disso, continua em 00000028 com cmp qword ptr [rsp+48h],0

Tudo isso por alguém que não usou o assembly i386 em 15 anos e que precisou pesquisar no google como estes .

(Qual é a minha maneira educada de dizer: "Por favor, faça alguma pesquisa antes de perguntar").

Is this assembly language specific to the processor?

A montagem é específica para um intervalo / família de processadores.

Por exemplo este trabalharia em um opéron da AMD, AMD K6, K7, intel celeron, intel core, ... (todo código i386-ish)

Enquanto coisas como esta funcionariam em um 6502, um 6510 e similar:
    sei
    lda # $ 0d
    sta $ 0314
    lda # $ c0
    sta $ 0315
    cli
    rts

If yes, do developers generally use this for debugging?

Eu presumo que a maioria não. Eu suponho que o dev médio. nem sequer sabe o que é montar ou código de máquina. Ele também não tem nenhuma ideia sobre bus de endereços, bus de dados, linhas de cache, arquitetura de memória ou qualquer coisa "profunda".

No entanto, alguns de nós fazem.

The only assembly language I have learned was for 8085, which I don't remember anymore.

Esse foi um precursor do código que você usou no exemplo.

    
por 01.08.2013 / 20:24
1

Sim, é uma desmontagem real e é específica do processador usado. Nesse caso, os registros "eax" indicam a arquitetura do microprocessador x86.

E não, os desenvolvedores não usam geralmente para depurar, eles usam o código-fonte (o que parece que você está perdendo por algum motivo). Mas é usado para encontrar exploits no código, bugs no compilador etc.

    
por 01.08.2013 / 20:21
1

.NEt código compila para um assembly Intermediário chamado MSIL ou CIL. Esse montador não é específico da CPU, como as linguagens assembler tradicionais, e é JIT (Just in Time) compilado para o assembly nativo em tempo de execução pela máquina virtual .Net Frameworks, muito parecido com o Java. O MSIL será executado em qualquer arquitetura de CPU para a qual exista uma versão do .Net Framework.

Aqui está uma introdução ao IL link

A maioria dos desenvolvedores modernos não usa a montagem, mas se você estiver trabalhando com montagens de código fechado, olhar para o IL é tudo que você pode fazer. Ele também pode ajudá-lo a otimizar seu código um pouco se você o conhece bem, mas apenas 1 em 20 ou mais. Os desenvolvedores do Net sempre teriam motivos para usá-lo explicitamente.

    
por 01.08.2013 / 20:39
1

Sim, essa linguagem de montagem parece específica para x64 processadores. Usando o Visual Studio, uma vez que ele só é fornecido no Windows, você provavelmente só encontrará a arquitetura Intel (embora o ARM também seja comum no Linux). No entanto, existem algumas instruções que são comuns a muitas arquiteturas (como mov , add e outras - test is tst no ARM).

Não, os desenvolvedores não usam isso para depuração. Se, no Visual Studio, houver um bug em algum código, provavelmente ele não é causado por um código para o qual ele não possui a fonte. Por exemplo, pode haver um ponteiro null passado acidentalmente para uma chamada de biblioteca. Como o VS leva você à linha de código em que o erro realmente causou um erro, parece que há um bug na função da biblioteca (quando realmente é o código que passou no ponteiro null em primeiro lugar, que tem o bug).

Embora você possa depurar no Assembly, isso geralmente é feito na linguagem com a qual o projeto está sendo construído (como C ou C++ ).

    
por 01.08.2013 / 20:25