Question

I am debugging a binary file in gdb. It was C code compiled by gcc on an Intel IA-32. I retrieved this output from objdump. I am most interested in the last line here:

08048d9e <func_1>
8048d9e:    55                      push   %ebp
8048d9f:    89 e5                   mov    %esp,%ebp
8048da1:    83 ec 18                sub    $0x18,%esp
8048da4:    c7 44 24 04 88 99 04    movl   $0x8049988,0x4(%esp)
8048dab:    08 
8048dac:    8b 45 08                mov    0x8(%ebp),%eax
8048daf:    89 04 24                mov    %eax,(%esp)
8048db2:    e8 54 01 00 00          call   8048f0b <strings_not_equal>

I believe this last line will compare the value found at the indicated address: 8048f0b. I attempt:

(gdb) x 0x8048f0b

and receive:

0x8048f0b <strings_not_equal>:  0x57e58955

Am I interpreting the assembly incorrectly? Is this the correct way to read the value of an address in gdb? I was kind of expecting to find a more ascii friendly hex value. I am interested in finding the stored string value that is compared against.

Also do you have a favorite gui tool that you like to use for this type of debugging? I have been thinking about trying ddd. I want to find an easier way to debug.

Answer 1

You are correctly reading the value at memory address 0x8048f0b, but the line call 8048f0b <strings_not_equal> indicates that this address is the start of a function (called strings_not_equal()). You wouldn’t expect that to be ASCII – you’d expect it to be more machine code.

If you’re looking for the function arguments to strings_not_equal(), those are being pushed onto the stack. The first argument is being copied from 0x8(%ebp), which is the first argument of func1(). The second argument is $0x8049988, which is presumably the address of a string.

If you want to print the contents of the address as a string, you can do that with x/s:

x/s 0x8049988