1

I have a simple c++ code as the following:

#include <iostream>

int main() {
    int a = 5;
    int *b = (int *) malloc(40);
    return 0;
}

Setting a breakpoint using GDB on line 5 and running disas will output the following:

Dump of assembler code for function main():
   0x0000000100000f60 <+0>: push   %rbp
   0x0000000100000f61 <+1>: mov    %rsp,%rbp
   0x0000000100000f64 <+4>: sub    $0x10,%rsp
   0x0000000100000f68 <+8>: mov    $0x28,%eax
   0x0000000100000f6d <+13>:    mov    %eax,%edi
   0x0000000100000f6f <+15>:    movl   $0x0,-0x4(%rbp)
   0x0000000100000f76 <+22>:    movl   $0x5,-0x8(%rbp)
=> 0x0000000100000f7d <+29>:    callq  0x100000f90
   0x0000000100000f82 <+34>:    xor    %ecx,%ecx
   0x0000000100000f84 <+36>:    mov    %rax,-0x10(%rbp)
   0x0000000100000f88 <+40>:    mov    %ecx,%eax
   0x0000000100000f8a <+42>:    add    $0x10,%rsp
   0x0000000100000f8e <+46>:    pop    %rbp
   0x0000000100000f8f <+47>:    retq  

Here are my questions:

1- Is all the stack needed for my app within this output? if I'm not mistaking the stack is pointed by rbp and moves down?

2- b is on the heap correct? I can see the address of it using x b.

3- Why does x a result in an error Cannot access memory at address 0x5? is it because 5 isn't actually anywhere on the memory? I can see it's part of the instruction movl $0x5,-0x8(%rbp)

Edit (more questions):

4- I have read that int a = 5; means variable a is created on the stack (memory) with the value 5, is this correct? when I look at the generated assembly, the value 5 is directly within the instruction set (movl $0x5,-0x8(%rbp), there is no reference to a memory location. If it IS on the memory then how can I see it's memory address? if it is NOT then why do I read that a is on the stack (memory)?

5- I know heap is also on the memory, is it visible from the above assembly?

6- I guess my biggest confusion and question is the relation between memory management and generated assembly, can I always point out what/where the heap/stack are given a assembly code? if not what else is needed?

1

1- Is all the stack needed for my app within this output? if I'm not mistaking the stack is pointed by rbp and moves down?

This question is somewhat ill-formed as written. Because your app is only a single function, all variables in the main() function are on the stack shown here. However, your app was likely built with some indicator of what its stack size should be and the OS allocated that much stack for your application, even if you didn't use all of it.

The rbp and rsp registers work in concert to keep data and return addresses and values on the stack.

2- b is on the heap correct? I can see the address of it using x b.

The variable b is on the stack, but the memory that it points to, which you allocated with malloc() is on the heap.

3- Why does x a result in an error Cannot access memory at address 0x5? is it because 5 isn't actually anywhere on the memory? I can see it's part of the instruction movl $0x5,-0x8(%rbp)

Note that the x command expects its argument to be an address. When you say x b you're saying you want gdb to show the memory pointed to by b. When you say x a you're saying you want gdb to show the memory pointed to by a. But a isn't a pointer. The x command is attempting to show you memory at address 5, which is a non-readable page of memory, so you get an error.

  • Thank you, I have added 3 more questions based your answer. – Joe Jan 21 at 23:56
1

4- I have read that int a = 5; means variable a is created on the stack (memory) with the value 5, is this correct?

Yes.

when I look at the generated assembly, the value 5 is directly within the instruction set (movl $0x5,-0x8(%rbp), there is no reference to a memory location.

But there is, rbp+8 is the memory address which the value gets written to.

If it IS on the memory then how can I see it's memory address? if it is NOT then why do I read that a is on the stack (memory)?

Try p &a.

5- I know heap is also on the memory, is it visible from the above assembly?

What exactly do you mean by visible? Your variable b will hold an address to memory inside the heap and you can access it in gdb as you did by using x b so its visible, yes.

6- I guess my biggest confusion and question is the relation between memory management and generated assembly, can I always point out what/where the heap/stack are given a assembly code? if not what else is needed?

Where the heap or stack is exactly is hard to tell, impossible from reading the assembly as the operating system and the memory allocator set them up at runtime. You'd need to actually run the program and check esp to learn where the stack (one of the stacks) is. Also, on linux, you can call pmap -x <process id> to learn a lot about the processes memory.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.