tags:

views:

194

answers:

2

I have the following problem: when I get a backtrace in C using the backtrace(3) function the symbols returned the name of the functions is easily determinable with the dwarf library and dladdr(3).

The problem is that if I have a simple function pointer (e.g. by passing it &function) the dladdr + dwarf functions can't help. It seems that the pointer is different from the one returned by backtrace(3) (it's not strange, since backtrace gets these function pointers straight from the stack).

My question is whether there is some method for resolving these names too? Also, I'd like to know exactly what is the difference between the two pointers.

Thanks!

UPDATE:

The difference between the pointers is quite significant:
The one I get with backtrace is: 0x8048ca4
The direct pointer version: 0x3ba838

Seems to me that the second one needs an offset.

A: 

addr2line(1) may be just the thing you're looking for.

John Williams
It's very nice but since this can only resolve the same kind of pointer that I already can (the one given by backtrace). Also, this is a command line function and I'm looking for a 'programmatical' solution.
terminus
+1  A: 

Making a guess from the substantial differences in the typical addresses you cited, one is from an actual shared library, and the other from your main executable. Reading between the lines of a man page for dladdr(3), it could be the case that if the symbol isn't located in a module that was loaded by dlopen(3) then it might not be able to reconstruct the matching file and symbol names.

I assume you haven't stripped the symbols off any module you care about here, or all bets are off. If the executable has symbols, then it should be possible to look in them for one that is an exact match for the address of any nameable function. A pointer to a function is just that, after all.

RBerteig
Both pointers in the example represent the same function.
terminus
Oh. Hmm. That puts a different face on it.... I don't know how dynamic linking is actually *implemented* in *nix, but if there are stubs for the loaded library then that could explain everything. The function pointer is pointing to a stub that jumps to the actual function in the library, perhaps.
RBerteig