How to evaluate functions in GDB?

Question

I wonder why evaluate function doesn't work in gdb? In my source file I include, when debugging in gdb, these examples are wrong evaluations.

(gdb) p pow(3,2)

$10 = 1

(gdb) p pow(3,3)

$11 = 1

(gdb) p sqrt(9)

$12 = 0

Solution 1

My guess is that the compiler and linker does some magic with those particular functions. Most likely to increase performance.

If you absolutely need pow() to be available in gdb then you can create your own wrapper function:

double mypow(double a, double b)
{
    return pow(a,b);
}

Maybe also wrap it into a #ifdef DEBUG or something to not clutter the final binary.

BTW, you will notice that other library functions can be called (and their return value printed), for instance:

(gdb) print printf("hello world")
$4 = 11

Solution 2

You need to tell gdb that it will find the return value in the floating point registers, not the normal ones, in addition to give the parameters the right types.

I.e.:

(gdb) p ((double(*)())pow)(2.,2.)

$1 = 4

Solution 3

The syntax for calling a function in gdb is

call pow(3,2)

Type

help call

at the gdb prompt for more information.

Solution 4

Actually, at least on my LINUX implementation of gcc, many of the math functions are replaced with variants specific to the types of their arguments via some fancy substitutions pulled in by math.h and bits/mathcalls.h (included from within math.h). As a consequence, functions like pow and exp are called instead as __pow or *__GI___exp (your results may vary depending on the types of the arguments and perhaps the particular version).

To identify what exactly the function is that is linked in to my code I put a break at a line where just that function is called, e.g. have a line in my code with b=exp(c);. Then I run in gdb up till that break point and then use the "step" command to enter the call from that line. Then I can use the "where" command to identify the name of the called routine. In my case that was *__GI___exp.

There are probably cleverer ways to get this information, however, I was not able to find the right name just by running the preprocessor alone (the -E option) or by looking at the assembly code generated (-s).

Solution 5

NAME
   pow, powf, powl - power functions

SYNOPSIS
   #include <math.h>

   double pow(double x, double y);

You shouldn't pass an int in the place of a double

 call pow( 3. , 2. )

Also, passing a single argument is not enough, you need two arguments just like the function expects

 wrong: call pow ( 3. )

View more solutions

Comments

[Tim]

Thanks! But call is still not correctly working (gdb) call sqrt(9) $14 = 0 (gdb) call pow(3,3) $15 = 1

[Isak Savo]

actually, passing ints work fine. not sure if it is just coincidence, but calling mypow (see my answer) with integers produce the correct result. I get no output from gdb when calling pow(2.0,2.0), but I do when calling mypow() with any numbers

[Isak Savo]

print will also call functions. In fact, I think the only difference is that call won't clutter the output when calling void functions

[falstro]

I know this is old, but if someone comes looking, here goes: For me it worked to just do p pow which gave me: $28 = {<text variable, no debug info>} 0x7ffff77ffbd0 <__pow>

[daj]

That's odd I get a value of $1 = 2

[mattypiper]

Correct answer is given below by anon

[Bebe Carabina]

Hello! I am an idiot and have been bashing my head open to figure out what the hell does double() mean?? I thought it meant a function pointer that can "return double pointer, and takes void args". So I tried reconverting to ((double)())pow)(2.,2.) -- failed! Why?

[bgoodr]

@mattypiper "given below by anon" needs a link in that comment. I think you intended to point to anon's answer .

[bgoodr]

@BebeCarabina I feel your frustration: I desire to avoid this typecasting-induced severe head-trauma. I posted a related question at How to evaluate functions in GDB without painful typecasting? to see if there is any solution.