ESP,EIP,EBP with c++ and asm

[adam2016]

Hey guys this may be a tough question to explain as I don't fully understand what is going on but I will try my best not to butcher it too much,

anyway I am in the process of learning assembly with the nasm assembler for linux I am following these tutorials https://www.tutorialspoint.com/assembly_programming/assembly_registers.htm

anyway while I was using immunity debugger of a C++ program I noticed it told you the esp(stack pointer) EBP(base pointer) and EIP (next instruction) so the thing that confuses me and my question is

is the esp,ebp,eip the same in a c++ program for an assembly program? for example when looking at the stack in immunity debugger is the stack in c++? or is the stack in assembly or opcode

maybe that didn't explain it what I am trying to say is the memory addresses you see on the stack for rip,esp and ebp are they taken from C++(high level language) converted into assembly(low level) with a compiler then converted into machine code with an assembler? so the stack isn't actually a cplusplus thing it's more of an assembly thing

and yes I know the ebp esp and ebp isn't assembly it's just registers holding memory addresses(pointers)

sorry If I couldn't explain that well,It's hard to try and express what I am thinking.

thanks

[jonnin]

Yes.
When you call a routine in c++, that is going to do the same things you see in assembly language -- it will push the status registers and data registers etc all onto the 'call stack', jump execution to the routine, execute the routine and pop the state back to what it was (apart from side effects like leaving a result in EAX or something) and the calling area will resume from there exactly the same way.

the C++ debugger has more information (about scope and classes and stuff) because the c++ compiler injects code and data into the program FOR the debugger to use. But at the machine level, they process code the same way. So the debugging information format is different, but the flow of a program is the same, does that make sense? The c++ extra debugging stuff is very heavy handed; that is why compiling with it removed in a 'release' mode gives a much, much faster executable. Some optmizations make it unpossible to understand the assembly or to show the debugging (due to elimination of blocks of code and other things) so debugging info usually disables most optimization and injects additional slowness that feed the debugger tool.

the call stack is a CPU thing, yes. Your c++ program is converted to machine language, that is what the compiler DOES. Most c++ compilers will give you the generated machine language as an assembly file so you can examine it, usually each c++ statement is commented into the assembly and then the statements needed to make that happen (can be 1 or pages, depends) follow.

[adam2016]

thanks Jonnin great answer :)

so at the end of the day,all languages such as java,c,c++ and assembly break down to machine code,

just a quick follow up on the compiler

so a c++ compiler translates c++ code directly into machine code? I always thought there was an assembly step where after the compiler has done its job it breaks it down to assembly then to machine code,so maybe the compiler takes care of this for us behind the scenes (translates the assembly to machine code)?

also I'm guessing some essential libraries in c and c++ must have been written in assembly,libraries that interact with the hardware itself such as ostream,ifstream,fstream

thanks .