Objdump fails on C++ -ggdb object files

[Craig Carey]

Here's a bug in objdump with the -g (--debugging) option.
The bug does not appear when the -ggdb option is not given to the
GCC C++ compiler.


File: "string.h" :
-----------------------------------------------------------------------
class __declspec(dllexport) T1 {
   public:
      int W1;
      ~T1() { }
      static T1 P1();
};
-----------------------------------------------------------------------

File: "string.cpp" :
-----------------------------------------------------------------------
#include "string.h"

T1 T1::P1() {
   T1 res;
   return res;
}
-----------------------------------------------------------------------

# Compile the C++ program using Gcc with the -ggdb option:

$ L:/gcc/bin/g++ -c -ggdb -Wall -o string.o string.cpp


# The latest 'objdump' fails on the object file:

$ /x/@cvs_redhat/src/binutils/objdump --debugging ./string.o
-----------------------------------------------------------------------
./string.o:     file format pe-i386

bad mangled name `2T1_ZN2T12P1Ev'
Last stabs entries before error:
n_type n_desc n_value  string
LSYM   0      00000000 signed char:t(0,10)address@hidden;r(0,10);-128;127;
LSYM   0      00000000 unsigned char:t(0,11)address@hidden;r(0,11);0;255;
LSYM   0      00000000 float:t(0,12)=r(0,1);4;0;
LSYM   0      00000000 double:t(0,13)=r(0,1);8;0;
LSYM   0      00000000 long double:t(0,14)=r(0,1);12;0;
LSYM   0      00000000 complex int:t(0,15)=s8real:(0,1),0,32;imag:(0,1),32,32;;
LSYM   0      00000000 complex float:t(0,16)=r(0,16);8;0;
LSYM   0      00000000 complex double:t(0,17)=r(0,17);16;0;
LSYM   0      00000000 complex long double:t(0,18)=r(0,18);24;0;
LSYM   0      00000000 wchar_t:t(0,19)address@hidden;r(0,19);0;65535;
LSYM   0      00000000 __builtin_va_list:t(0,20)=*(0,2)
LSYM   0      00000000 bool:t(0,21)address@hidden;-16;
LSYM   0      00000000 __vtbl_ptr_type:t(0,22)=*(0,23)=f(0,1)
BINCL  0      00000000 string.cpp
BINCL  0      00000000 string.h
LSYM   2      00000000 
T1:Tt(2,1)=s4W1:(0,1),0,32;operator=::(2,2)=#(2,1),(2,3)=&(2,1),(2,4)=*(2,1),(2,5)=&(2,6)=k(2,1),(2,7)=(2,7);:_ZN2T1aSERKS_;2A.;__base_ctor::(2,8)=#(2,1),(2,7),(2,4),(2,5),(2,7);:_ZN2T1C2ERKS_;2A.;__comp_ctor::(2,8):_ZN2T1C1ERKS_;2A.;__base_ctor::(2,9)=#(2,1),(2,7),(2,4),(2,7);:_ZN2T1C2Ev;2A.;__comp_ctor::(2,9):_ZN2T1C1Ev;2A.;__base_dtor::(2,10)=#(2,1),(2,7),(2,4),(2,7);:_ZN2T1D2Ev;2A.;__comp_dtor::(2,10):_ZN2T1D1Ev;2A.;P1::(2,11)=f(2,1):_ZN2T12P1Ev;2A?;;
-----------------------------------------------------------------------

A comment in the file describes teh case of the error.

Binutils file /src/binutils/stabs.c says

Line 4073:
>       case '_':
>         /* At the outermost level, we cannot have a return type
>            specified, so if we run into another '_' at this point we
>            are dealing with a mangled name that is either bogus, or
>            has been mangled by some algorithm we don't know how to
>            deal with.  So just reject the entire demangling.  */
>         stab_bad_demangle (orig);
>         return FALSE;

*pp = "_ZN2T12P1Ev", orig = "2T1_ZN2T12P1Ev".

------------
"man gcc":
>      -ggdb
>          Produce debugging information for use by GDB.  This means to use
>          the most expressive format available (DWARF 2, stabs, or the native
>          format if neither of those are supported), including GDB extensions
>          if at all possible.



Craig Carey
21 June 2003