How to find the function symbol in nm or objdump when using shared_ptr for abstract class?

Jul 23, 2011 at 9:01am
Hi,

I use shared_ptr for an abstract class ABC as follows:

typedef boost::shared_ptr<ABC> ABCPtr;
ABCPtr get_ABC_ptr()
{
return ABCPtr(new ABCImpl());
}

int main(void)
{
ABCPtr abc_ptr = get_ABC_ptr();
abc_ptr->func_in_ABC();
}

In the above code, ABC is abstract class. ABCImpl class is the
implementation of ABC.abc_ptr points to an ABCImpl objects. In main(),
abc_ptr will call one of the member function in ABC class. The compile
is successful. But when I use nm or objdump, I could only see the
symbol for abc_ptr. There is no symbol displayed for func_in_ABC().

0000000000000000 W boost::shared_ptr<ABC>::operator->() const

Anyone knows why, or how an I get the output for the symbol for
func_in_ABC()?

Thank you.
Jul 23, 2011 at 2:59pm
I am only conjecturing here.

If func_in_ABC's definition is seen by the compiler when it is compiling main, and the function body is empty, then the compiler is optimizing the function away.

Jul 24, 2011 at 12:30am
No. There are some implementation in ABCImpl::func_in_ABC(). Since ABC is abstract class, there are no implementation there. But I think at least, there should be some symbol for func_in_ABC() when it's called by main(). Rite?

If there is no symbol for func_in_ABC() in main, why it can't pass the compilation, when I change the definition of func_in_ABC() in class ABC and ABCImpl?
Jul 24, 2011 at 4:51am
Again, conjecturing.

If ABC is abstract, then func_in_ABC() is a virtual function. Virtual functions only rarely can be called by name; that is the whole point of runtime polymorphism.

That being the case, the function is being called by looking up its address in the vtable. That means that the compiler needn't even generate a symbol for the function name.



Jul 24, 2011 at 8:44am
Yes. It's true. But I think there are function signature check during compilation. That means the symbol of func_in_ABC is saved in the .o file somewhere or in vtable. How can I lookup the vtable in nm or objdump to get at least the function name of the share_ptr object (like func_in_ABC in this case).

To avoid confusion, I paste my code here:

In ABC.h:
1
2
3
4
5
6
7
8
9
#include <boost/shared_ptr.hpp>

class ABC
{
    public:
        virtual void func_in_ABC(const int param) = 0;
};
typedef boost::shared_ptr<ABC> ABCPtr;
ABCPtr get_ABC_ptr();


In ABCImpl.h:
1
2
3
4
5
6
7
8
9
10
#include "ABC.h"

class ABCImpl : public ABC
{
    public:
        ABCImpl();
        void func_in_ABC(const int param);
    private:
        int data;
};


In ABCImpl.cpp:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#include "ABCImpl.h"

ABCPtr get_ABC_ptr()
{
        return ABCPtr(new ABCImpl());
}

ABCImpl::ABCImpl()
{
}

void ABCImpl::func_in_ABC(const int param)
{
    data = param;
}


In caller function D.cpp:
1
2
3
4
5
6
7
8
#include "D.h"
#include "ABC.h"

void D::call_ABC()
{
    ABCPtr abc_ptr = get_ABC_ptr();
    abc_ptr->func_in_ABC(100);
}


The output of D.o from nm is:
1
2
3
4
5
6
7
         U _Unwind_Resume
         U get_ABC_ptr()
0000000000000000 T D::call_ABC()
0000000000000000 W boost::shared_ptr<ABC>::operator->() const
0000000000000000 r boost::shared_ptr<ABC>::operator->() const::__PRETTY_FUNCTION__
         U __assert_fail
         U __gxx_personality_v0
Jul 24, 2011 at 3:18pm
The only thing the compiler needs at compile time is the header file. During the compilation process the compiler never looks at .o files. Only during linking.

Based on your code, the func_in_ABC symbol would be found in ABCImpl.o, not D.o.

Topic archived. No new replies allowed.