Thread: GDB and inheritance

  1. #1
    Registered User
    Join Date
    Apr 2007
    Posts
    51

    GDB and inheritance

    I have a class that inherits many variables from the parent. The program works in that all the variables are accessable in the program.

    I am having a problem viewing the data in GDB. A place holder comes up but reports no data. Is there a flag I need to compile with or start gdb with or something? Any help or guidance is appreciated.

    I am using: Suse 10.1, gcc 4.1.0-25, gdb 6.4.19

    I have tried the variables in the top class as protected (first) and public.

  2. #2
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,057
    There doesn't seem to be anything special necessary, for me at least.
    Code:
    $ cat basegdb.cpp
    #include <iostream>
    
    class object {
    private:
        int id;
    public:
        object(int id) : id(id) {}
    };
    
    class physical_object : public object {
    private:
        bool solid;
    public:
        physical_object(int id, bool solid) : object(id), solid(solid) {}
    };
    
    int main() {
        physical_object o(42, true);
        return 0;
    }
    $ g++ -g basegdb.cpp -o basegdb
    $ gdb ./basegdb
    GNU gdb Red Hat Linux (6.5-37.el5_2.2rh)
    Copyright (C) 2006 Free Software Foundation, Inc.
    GDB is free software, covered by the GNU General Public License, and you are
    welcome to change it and/or distribute copies of it under certain conditions.
    Type "show copying" to see the conditions.
    There is absolutely no warranty for GDB.  Type "show warranty" for details.
    This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".
    
    (gdb) break main
    Breakpoint 1 at 0x8048535: file basegdb.cpp, line 18.
    (gdb) r
    Starting program: ./basegdb
    
    Breakpoint 1, main () at basegdb.cpp:18
    18          physical_object o(42, true);
    (gdb) n
    19          return 0;
    (gdb) p o
    $1 = {<object> = {id = 42}, solid = true}
    (gdb)
    Note that I'm sure you'd need to compile all of your source files with debugging information available. Also, if you have a pointer to a base class which actually points to a derived class, you may need to cast the pointer if you want to see derived class data; but this doesn't seem to be your problem.
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  3. #3
    Registered User
    Join Date
    Apr 2007
    Posts
    51
    Quote Originally Posted by dwks View Post
    There doesn't seem to be anything special necessary, for me at least.......

    Note that I'm sure you'd need to compile all of your source files with debugging information available. Also, if you have a pointer to a base class which actually points to a derived class, you may need to cast the pointer if you want to see derived class data; but this doesn't seem to be your problem.

    Code:
    class object {
    private:
        int id;
    public:
        object(int id) : id(id) {}
        int myBaseData;
    };
    
    class physical_object : public object {
    private:
        bool solid;
    public:
        physical_object(int id, bool solid) : object(id), solid(solid) {}
        void editBaseData(int newData){myBaseData = newData;};
    };
    
    int main() {
        physical_object o(42, true);
        o.editBaseData(5);
        return 0;
    }
    
    
    $ g++ -g basegdb.cpp -o basegdb
    $ gdb ./basegdb
    
    (gdb) break main
    Breakpoint 1 at 0x8048535: file basegdb.cpp, line 18.
    (gdb) r
    Starting program: ./basegdb
    
    Breakpoint 1, main () at basegdb.cpp:18
    18          physical_object o(42, true);
    (gdb) n
    19          return 0;
    (gdb) p o
    $1 = {<> = no data}
    (gdb)
    The gdb output is from memory, but basicly what it reports. I can see all the data in the physical_object class except for the base class data. I compile with -g3, -dwarf-2 -Wall

  4. #4
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,057
    I'm assuming you mean -g3 -gdwarf-2 -Wall?

    Anyway, I can't think of what might be wrong. I can only suggest that you try a simple example like the one I have posted, and if that works but your code doesn't, then it must be the way in which your project is being built.
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  5. #5
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by dwks View Post
    I'm assuming you mean -g3 -gdwarf-2 -Wall?

    Anyway, I can't think of what might be wrong. I can only suggest that you try a simple example like the one I have posted, and if that works but your code doesn't, then it must be the way in which your project is being built.
    Or gdb is not working as it should.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  6. #6
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,057
    Perhaps. Have you ever used GDB in this way before?

    Also: http://developer.apple.com/documenta...db/gdb_14.html
    Code:
    set opaque-type-resolution off
        Tell GDB not to resolve opaque types. In this case, the type is printed as follows:
    
        {<no data fields>}
    Maybe you could try turning that setting on? . . . .

    This isn't very helpful. http://osdir.com/ml/gdb.bugs.discuss.../msg00016.html Your version of GDB looks reasonably recent, though I have 6.8 myself.
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  7. #7
    Registered User
    Join Date
    Apr 2007
    Posts
    51
    Quote Originally Posted by dwks View Post
    I'm assuming you mean -g3 -gdwarf-2 -Wall?

    Anyway, I can't think of what might be wrong. I can only suggest that you try a simple example like the one I have posted, and if that works but your code doesn't, then it must be the way in which your project is being built.

    Of course gdwarf-2.

    I tried a generic class/subclass program and it worked fine. I guess it is something I am doing not quite right.

    Thanks for the help...

  8. #8
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by markcole View Post
    Of course gdwarf-2.

    I tried a generic class/subclass program and it worked fine. I guess it is something I am doing not quite right.

    Thanks for the help...
    If you want to get to the bottom of the problem, try to reduce your existing large project and strip it down to the minimum of what is needed to reproduce it. If you can produce something relatively small that can reproduce the problem, then I'd say post it here. And unless someone comes up with an immediate solution (which may be "upgrade to GDB version x"), then it's time to post it to the GDB bugzilla or some such. [Of course, it could be the compiler generating crap debug info too!].

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  9. #9
    Registered User
    Join Date
    Apr 2007
    Posts
    51
    Well I "figured out" what is wrong. Kind of.

    The base class has some virtual functions in it and therefore I had the destructor declared as virtual. Additionally, I have the base class compiled as a library and it is linked to the main project.

    When the destructor is declared as virtual I cannot see the data in GDB. If the destructor is not declared virtual, I CAN see the data fields.

    I am not sure why. If anyone has any hints or suggestions I would be greatful.

    I realize this is less a C++ issue/question and more a GDB/gcc question, but thanks for the assistance any who.

  10. #10
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Obvious/stupid question: Is your library compiled with debug info too?

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  11. #11
    Registered User
    Join Date
    Apr 2007
    Posts
    51
    Quote Originally Posted by matsp View Post
    Obvious/stupid question: Is your library compiled with debug info too?

    --
    Mats
    Normally I would agree that it is a "Obvious/stupid question", however in this case...

    Thanks for the second set of eyes.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 16
    Last Post: 06-08-2009, 03:03 PM