Is the disassembly shown by Visual studio actually assembly?

Question

Sometimes when I debug using visual studio, I get this option no source code available, show disassembly, which when clicked shows stuff like this

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

Is this assembly language specific to the processor? If yes, do developers generally use this for debugging? The only assembly language I have learned was for 8085, which I don't remember anymore.

Answer 1

Yes, this is assembly.

0000001f  test        eax,eax 
00000021  je          0000000000000028 

test eax,eax checks if eax register is zero.
If this is the case it jump to address 0x28. (je is jump equal), skipping the next call. If it is not zero it does not skip the next call.
Regardless of that it then continues at 00000028 with cmp qword ptr [rsp+48h],0

All of this by someone who has not used i386 assembly in 15 years and who had to google for hits like these.

(Which is my polite way of saying: "Please do some research before asking").

Is this assembly language specific to the processor?

Assembly is specific to a processor range/family.

E.g. this one would work on an AMD opteron, AMD K6, K7, intel celeron, intel core, ... (all i386-ish code)

While things like this would work on a 6502, a 6510 and similar:
sei
lda #$0d
sta $0314
lda #$c0
sta $0315
cli
rts

If yes, do developers generally use this for debugging?

I assume most do not. I assume the average dev. does not even know what assemble or machine code is. Nor has (s)he any idea about address busses, data busses, cache lines, memory architecture or anything 'deep'.

However some of us do.

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

That was a precursor to the code you used in the example.

Answer 2

Yes, it is actual disassembly and it is specific to processor used. In this case, "eax" registers indicate x86 microprocessor architecture.

And no, developers do not generally use this for debugging, they use source code instead (which you seem to be missing for some reason). But it is used for finding exploits in code, bugs in compiler etc.

Answer 3

.NEt code compiles to a Intermediary assembly language called MSIL or CIL. This assembler is not CPU specific like traditional assembler languages, and is JIT (Just in Time) compiled to native Assembly at run time by the .Net Frameworks virtual machine, much like Java does. MSIL will run on any CPU architecture for which there is a version of the .Net Framework.

Here is an introduction to IL http://www.codeproject.com/Articles/3778/Introduction-to-IL-Assembly-Language

Most modern developers do not use the assembly, but if you are working with closed source assemblies, looking at the IL is all you can do. it may also help you optimize your code a little if you know it well, but only 1 in 20 or so .Net developers would ever have reason to use it explicitly.

Answer 4

Yes, that assembly language looks specific to x64 processors. Using Visual Studio, since it only comes on Windows, you are likely to only come across Intel architecture, (although ARM is also common in Linux). There are some instructions, however, that are common to a lot of architectures (like mov, add, and others - test is tst in ARM).

No, developers don't use this for debugging. If, in Visual Studio, there is a bug in some code, it is probably not caused by code that they don't have the source for. For example, there might be a null pointer accidentally passed to a library call. Since VS brings you to the line of code where the bug actually caused an error, it makes it look like there is a bug in the library function (when really it's the code that passed a null pointer in the first place that has the bug).

Although you can debug in Assembly, it is usually done in the language that the project is being built with (like C or C++).