gdb debugging integer printing information

Question

I am trying to find out how to print an integer value (I saw that it is x/d) but I am missing something.

So, my code is the following

 1  #include <stdio.h>
 2  main(){
 3    int a;
 4    int b;
 5    int c;
 6    int d;
 7    int multiplied;
 8    a = 5;
 9    b = 6;
10    c = 7;
11    d = adding(a,b,c);
12    multiplied = multiply(a,b,c);
13    printf("The value of d is %d \n",d);
14    printf("The multiplied values are %d \n", multiplied);
15  }
16  int adding(a,b,c){
17    int e;
18    e = a+b+c;
19    return e;
20  }
21  int multiply(a,b,c){
22    int f = a*b*c;
23    return f;
24  }

// I compiled with -q and I want to print the values of the variables (from their addresses) So...

(gdb) disassemble main
0x080483ed <+9>:    mov    DWORD PTR [esp+0x2c],0x5
0x080483f5 <+17>:   mov    DWORD PTR [esp+0x28],0x6
0x080483fd <+25>:   mov    DWORD PTR [esp+0x24],0x7
0x08048405 <+33>:   mov    eax,DWORD PTR [esp+0x24] <code>

I put some breakpoints in main / multiply / adding and then I was trying to do the following thing.

I used print $esp+0x24 and (gdb) x/4d 0xbffff47c but im not getting the right answers back.

I used the 4d because I thought that an integer is 4 bytes (or maybe again im missing something) but the results arent showing the value 5. Can you please help me? Thanks and sorry for the bad output / format of gdb.. seriously i cant understand whats wrong

(gdb) print $esp+0x2c
$2 = (void *) 0xbffff494
(gdb) print $esp+0x28
$3 = (void *) 0xbffff490
(gdb) print $esp+0x24
$4 = (void *) 0xbffff48c
(gdb) x/d 0xbffff494
0xbffff494: -1208180748
(gdb) x/d 0xbffff490
0xbffff490: -1208179932
(gdb) x/d 0xbffff48c
0xbffff48c: 134513881

Also this happens ofcourse after the first breakpoint of main and actually the same values are coming all the time in all breakpoints (except the one before main...)

Another interesting thing that I found is the following... Im sure that the first values are garbages. But why it considers 0x5 as an address when it should print the actual value?

Breakpoint 1, main () at functioncalling.c:10
10  a = 5;
(gdb) x/s a
0xb7fc9ff4: "|M\025"
(gdb) cont
Continuing.
Breakpoint 3, adding (a=5, b=6, c=7) at functioncalling.c:21
21  e = a+b+c;
(gdb) x/s a
0x5:    <Address 0x5 out of bounds>

Answer 1

I compiled your program with -g and no optimization, and set a breakpoint before line 11. My stack addresses are a bit different from yours, which isn't surprising given the variety of systems out there.

(gdb) print $esp+0x2c
$2 = (void *) 0xbffff44c

This is printing the address of a. To confirm:

(gdb) print &a
$4 = (int *) 0xbffff44c

Use x/wd to show a 4-byte integer in decimal.

(gdb) x/wd $esp+0x2c
0xbffff44c: 5

x/4d will show 4 values (4 is the repeat count) starting at the address. If you omit the size letter w here, the x command will default to the size previously used.

(gdb) x/4d $esp+0x2c
0xbffff44c: 5   134513856   0   -1073744680

There's your 5. As for the 3 other numbers, they are things further up the stack.

(gdb) x/4a $esp+0x2c
0xbffff44c: 0x5 0x80484c0 <__libc_csu_init> 0x0 0xbffff4d8

Your next question:

Another interesting thing that I found is the following... Im sure that the first values are garbages. But why it considers 0x5 as an address when it should print the actual value?

Breakpoint 3, adding (a=5, b=6, c=7) at functioncalling.c:21
21  e = a+b+c;
(gdb) x/s a
0x5:    <Address 0x5 out of bounds>

The x command, when given a program's variable as its argument, retrieves its value and uses that as the address. x/s a means to retrieve the value in a and use it as the starting address of a NUL-terminated string. If a were of type char * and contained a suitable value, x/s would print sensible output. To print a's actual value, give the x command the argument &a.

(gdb) x/wd &a
0xbffff44c: 5

This may seem counterintuitive. Just consider the x command to operate just like the C statement printf(fmt, *(argument)) would. The argument to the x command is almost always a literal memory address or an address expression involving the stack pointer, base pointer, or pc registers.