Hello

I started programming in ASM as a hobby. I wrote a simple program in C which assigns the value 5 to a variable and the quits in order to see how this assignment looks.

So it's something like this:

I compile with debug symbols and I run the program.
I then disassemble the main function and I see this.

I make a break for "int x = 5" meaning "mov DWORD PTR [ebp-4],0x5".

Now the interesting thing happens. While the program is stopped at this line I chose to examine what instruction is on ebp-4 (if there is something there). So I type "x/i $ebp-4".
And I get this:

Should not this location be full of garbage or something like that? I mean it will be overwritten with 5 right? So why is there an asm instruction at $ebp-4?

There is an asm instruction almost anywhere there is a value, because most values can be disassembled as asm instructions.

If you ask to see it as an asm instruction, that is what you get.

1 members found this post helpful.

Thanks a lot. This is most interesting!

Anyone care to explain what all that stuff is before mov DWORD PTR? Why is it subtracting 0 from esp?

Those two instructions at the beginning balanced by that one instruction before the return, are the simple (not necessarily efficient) way to establish a basic stack frame for a function.

The old value of ebp is pushed on the stack, then ebp is set to point to where that old ebp was saved.

The leave instruction uses ebp to restore the prior value of both ebp and esp. So, prior to leave, it is not necessary to clean up any excess positions (nested function parameters, etc.) that might have been pushed by this function.

Reserving 8 bytes of space at [ebp-8].

I think the stack was being kept 8-byte aligned. So the need to allocate 4 bytes for x caused it to allocate 8 bytes total.

16-byte aligning the stack. Some operations (none of which are in this function) need a 16-byte aligned stack. But the calling convention is not 16-byte aligned. So any function that thinks it needs 16-byte alignment must create that for itself.

I guess it was reserving space for all of the variables that need 16 byte alignment. The total size of such variables in this function appears to be zero.

Non optimized code generation was following a general pattern of code for entry to a function, without caring that the steps were pointless in this trivial function.

Everything but the ret was pointless. x could be optimized away, so you don't need to allocate space for it nor set its value. The stack frame is optional. If you aren't calling nested functions nor need 16 byte alignment of the stack, there is no need for the overhead of using ebp.

There's no help for it. John. You. Are. A. God.


*How* do you know these things?


Did you write compilers or something?

I expect several of the experts in this forum know all that, but this time didn't have patience to re explain old stuff.

I know it mainly from many occasions of using asm level debugging to help programmers I work with in diagnosing the occasional bug in C++ code that makes no sense when looked at in the debugger at a source level.

I never wrote a C++ compiler, nor a compiler that generates 32-bit or 64-bit x86 output. It has been a very long time since I wrote a compiler that generates 16-bit x86 (and that wasn't for much of a language) and even longer since I wrote a C compiler.

The "compiler" that is part of my current responsibilities at work generates C++ code as its output (then it uses Mingw to create a .dll from the C++ code). Many people wouldn't even call our part a "compiler"; Mingw is the compiler and we haven't touched the internals of Mingw. Anyway, low level details of compiler output such as discussed earlier in this thread don't enter into that project at all. I'm not sure about LQ policy regarding next detail: I have an opening in my team (in Burlington Ma.) for someone experienced in the kind of data structures and processing are typical inside a compiler to work on that project, which might not really be a "compiler" but internally uses the same techniques as a compiler. If you know someone who might fit that job, please tell me. (Overly optimistic amateurs considered only if you know Mingw internals a lot better than I do myself. Otherwise only those with relevant work experience. We won't be modifying Mingw internals, but understanding them helps and is also a good example of the kind of skill required.)