7

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.

terminus
  • 13,745
  • 8
  • 34
  • 37
  • Are the pointers *very* different, or just off by a little bit? – bstpierre Aug 27 '10 at 20:08
  • 1
    The pointers found on the stack are generally the address of the instruction just after the call to the current function. They are generally not the same as pointers to the entry of any function. – RBerteig Aug 27 '10 at 21:49
  • @RBerteig: So this means that the real entry point eighter contains a jump instruction to the real entry or is there something more sinister? – terminus Aug 27 '10 at 22:13
  • It sounds like you are getting a pointer into the PLT, but you might want to post a small program that demonstrates the issue. – caf Aug 27 '10 at 23:55

2 Answers2

1

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
  • 41,948
  • 7
  • 88
  • 128
  • 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 Aug 28 '10 at 01:21
0

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

John Williams
  • 113
  • 1
  • 6
  • 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 Aug 27 '10 at 21:32