0

I will narrow down my questions:

The entry address in GDB stays the same for the same program (even after reboot, and after rewriting the source code).

Why is that?

For example 0x80483f4 is the starting address.

**0x80483f4** <main()>              push   %ebp                                │
   │0x80483f5 <main()+1>            mov    %esp,%ebp                           │
   │0x80483f7 <main()+3>            sub    $0x10,%esp                          │
   │0x80483fa <main()+6>            movl   $0x3,-0x4(%ebp)                     │
   │0x8048401 <main()+13>           movl   $0x3,-0x8(%ebp)                     │
   │0x8048408 <main()+20>           mov    $0x0,%eax                           │
   │0x804840d <main()+25>           leave                                      │
   │0x804840e <main()+26>           ret

Beside that, the value we get from, let say, 0x80483fa, is always the same.

$2 = 0x80483fa <main()+6>
(gdb) x $2
0x80483fa <main()+6>:   0x3fc45c7
(gdb) p 0x3fc45c7
$3 = 66864583   <-- even after reboot.

What does this suggest me?
I am interested in the values before and after each assignment (say c = a+b later), without using breakpoints to step through one line at a time.

The source code:

int main()
{ 
   int b = 3;
   int a = 3;
return 0;   
}

Can someone please explain this to me? Thanks. (I would also mark this as homework, although it really isn't.)

CppLearner
  • 16,273
  • 32
  • 108
  • 163

2 Answers2

2

For example 0x80483f4 is the starting address.

This is likely. Unless you have PIE (position independent executables), it will stay the same (for one binary) forever.

$2 = 0x80483fa <main()+6>
(gdb) x $2
0x80483fa <main()+6>:   0x3fc45c7

That is the binary representation of the instructions at main()+6. Will never change in one binary.

(gdb) p 0x3fc45c7
$3 = 66864583   <-- even after reboot.

That means 0x3fc45c7 is 66864583 in decimal...

Note that none of this has anything to do with a or b.

BTW the best way to get values of variables "before assignment" is to printf them before the assignment.

jpalecek
  • 47,058
  • 7
  • 102
  • 144
  • without using the breakpoint, is there really a way to look into what value is stored in address 0x80483fa at this point? (well using breakpoint would mean I am in execution, and hence I can look up at the registers.) thanks jpalecek – CppLearner Oct 01 '11 at 23:57
  • you are right. however, I cannot use printf (or cout) directly from source code. I have to, use GDB to look into memory. I even tried other things such as ndisasm and hexdump. They only tell me the instructions. – CppLearner Oct 01 '11 at 23:59
  • You already have that value - it's 0x3fc45c7. But the address is wrong, it points to the code, not data. – jpalecek Oct 02 '11 at 00:00
  • BTW, `a` is an automatic variable, which lives on the stack, and not in the executable. Memory for it will only be allocated in `main()`. – jpalecek Oct 02 '11 at 00:01
  • you are right. When this program runs, it creates a stack frame. But this stack frame will vanished after execution. According to the code, it should allocate 16 bytes below ebp(decrement), right? So I should be able to find out where a SUPPOSED to live in, right? – CppLearner Oct 02 '11 at 00:11
  • Ah. If you just want the address of the variables, its `$ebp-4`. So either `x $ebp-4` or `p *(int*)($ebp-4)`. Or -8 for the other variable. – jpalecek Oct 02 '11 at 00:14
  • yes. but unfortunately, i cannot use these because they are not available (no breakpoint, afte execution registers and stacks are all cleaned). so commands like info locals, info registers will be no used. i opened a thread, and if you have time,may you give me your two cents? :D thanks – CppLearner Oct 02 '11 at 02:50
0

Your program is (at least partially) statically linked, and main() almost certainly is. Rebooting your computer isn't going to change that statically linked part of the executable.

David Hammen
  • 32,454
  • 9
  • 60
  • 108
  • Static linking has nothing to do with *anything* here. – Employed Russian Oct 02 '11 at 02:00
  • @EmployedRussian: Static linking has everything to do with the first question raised, which was "*The entry address in GDB stays the same for the same program (even after reboot, and after rewriting the source code). Why is that?*" The address reported is a virtual address, not a physical address. That virtual address will not change without relinking the program. – David Hammen Oct 02 '11 at 04:50
  • @JohnWong: What is there to correct? There is nothing wrong here. – David Hammen Oct 02 '11 at 04:54