1

I want to use backtrace() and get function address for tracing purpose. I want to store function address from backtrace() during run time, and use it for analysis later on (e.g. load back function name, look at call stats etc using dladdr()). While doing that, I was trying to look at static address of a class member function.

Alib.so, A.h:

class A
{
public:
    void print_addr();
};

A.cpp

#include "A.h"
#include <iostream>

void A::print_addr()
{
   std::cout << (void*)&A::print_addr << std::endl;
}

main.cpp

#include <iostream>
#include "Alib/A.h"

int main()
{
   std::cout << (void*) &A::print_addr << std::endl;
   // if put the line below, with the line above, output is the same
   // It seems whenever the code pull in &A::print_addr into main, addr is 
   // always the same.  Only different if print .so itself
   // A a; a.print_address();
   return;
}

this outputs:

0x400870

If I rerun main multiple times, it gives me the same address. If I change main.cpp to this:

int main()
{
   A a;
   a.print_addr();
   return 0;
}

Outputs is different every time I run main executable, even without recompiling .so or main:

0x7fae48524aa0

The reason I'm checking this is that I'd like to use backtrace() to get function info (address) on the current stack function for tracing and it acts very similar. I tried call backtrace() within a .so library function, and get symbol info on the function using backtrace() and dladdr() on the current stack function. Printing a function address in .so versus doing it in main gives a different address. How can I use the function address for dladdr() to get info, such as symbol name?

Is there something to a class member function address mapped differently in .so and in main()?

EDITS: Re-word and give more code example to explain the problem.

surfcode
  • 445
  • 1
  • 5
  • 20
  • You changed your source and recompiled. All addresses may change. Why do you think they should be the same? – Kirill Kobelev Dec 23 '16 at 08:03
  • @kirill don't really need them to be the same. But using the address returned in dladdr() from backtrace(), if .so does not change, I should expect dladdr( add, info ) to return me back the correct function name? It seems like I can't. – surfcode Dec 23 '16 at 08:21
  • Print this address twice from both locations. I bet you will see the same number. I do not think that func being member of a class is important here. – Kirill Kobelev Dec 23 '16 at 08:26
  • so if I write a main() program, run some code and store address of &A::foo into a file. Afterwards, I write another program, link with the same .so where A::foo resides. Using that stored address of &A::foo, can I use dladdr() to load back symbol info? It seems every time I rerun the main, I get a different address for &A::foo. – surfcode Dec 23 '16 at 10:16
  • Edited the questions to give examples. – surfcode Dec 23 '16 at 10:34
  • 1
    It looks that you have wrong idea that the place where you print address is important. It is not. The rules how OS loads your program depending how you have built it may be complicated. There is nothing wrong if system will load your app into different addresses on each run. You need to focus on these rules. – Kirill Kobelev Dec 23 '16 at 11:00
  • @KirillKobelev: thanks for the reply. It is ok to have different address, but if I want to persist the address to a file, as in the question, then in another program, use dladdr(address, ...) to load back symbol info, it seems I can't load back the function name using the one got from the .so (the one that changes). I only care about being able to do that. – surfcode Dec 23 '16 at 11:06
  • This isn't a c++ question, it is a "whichever OSs you need this to run on" question. The OS can place the function in a different place every time you run the program (see https://en.wikipedia.org/wiki/Address_space_layout_randomization) – Caleth Dec 23 '16 at 12:29
  • @Caleth - thank you. So does that mean I can never use a persistent function address in prior runs to find the symbol info again loading the same .so? – surfcode Dec 24 '16 at 02:12

0 Answers0