0

I'm attempting to use GDB to debug a PowerPC ELF image compiled by the Green Hills GHS compiler from C++ source. The GHS MULTI debugger uses a proprietary debugging format, but the compiler provides a -dwarf2 option to produce native DWARF-2 debugging information as well. GDB is able to read at least some information from the DWARF-2, and can do things like map line numbers to addresses and find the addresses of symbols, but many things such printing local variables in member functions do not work.

I compiled this very simple program with g++ targeting x86 and GHS targeting PowerPC to compare the two. The -dwarf2 and -G flags were set in the top level .gpj for GHS to produce DWARF-2 debug information. I did a readelf --debug-dump and confirmed that GHS did generate what looks like reasonably correct DWARF-2.

class ClassA {
public:
  int Method(bool arg) {
    int local_1 = arg * 2;
    member_var_ = local_1;
    return local_1;
  }
  int member_var_;
};

int FuncA(int arg) {
  int local_2 = arg * 2;
  return local_2;
}

double global_a = 1;

namespace NamespaceA {
  int FuncB(int arg) {
    int local_3 = arg * 2;
    return local_3;
  }
}

int main(int argc, char *argv[]) {  
  ClassA a;
  return a.Method(true);
}

GDB is able to list all the functions from the g++ compiled ELF:

gdb hello
...
Reading symbols from hello...done.
(gdb) info func
All defined functions:

File hello.cc:
int ClassA::Method(bool);
int FuncA(int);
int NamespaceA::FuncB(int);
int main(int, char**);

GDB does not list the member function or the function declared inside a namespace from the GHS compiled ELF:

gdb hello
...
Reading symbols from hello...done.
(gdb) info func
All defined functions:

File src/hello.cc:
int FuncA(int);
int main(int, char**);

Non-debugging symbols:
...

Is there an incompatibility between GHS generated DWARF-2 and GDB?

Adam
  • 389
  • 1
  • 4
  • 8

1 Answers1

2

For namespaces support you need at least DWARF3 format. It looks like DWARF2 is unable to represent C++ namespaces because it was completed before C++ namespaces were even considered, see DWARF3 features:

3 Major New Features

3.1 C++ , including Namespaces

DWARF2 was completed before the C++ Standard and before C++ namespaces were even considered. DWARF3 provides a complete set of features using DW TAG namespace, DW TAG imported declaration, DW AT import, and DW AT extension that enables an implementation to represent the visible namespaces correctly in every function. Implementations may choose to emit a single namespace declaration showing the complete namespace at the end of the compilation unit as this is simpler, though it loses some of the details of some uses of C++ Namespaces.

Community
  • 1
  • 1
ks1322
  • 33,961
  • 14
  • 109
  • 164
  • Thanks for that info. I don't think the lack of namespace support in DWARF2 is at the root of the problem I'm seeing. When I compiled with g++ and -gdwarf-2 I was able to list the function declared inside a namespace. I'm not really sure why would a debugger even needs to know about namespaces. It looks like the namespace just becomes part of the fully qualified symbol names. Maybe it would allow the debugger to understand using directives and namespace aliases? – Adam Feb 20 '18 at 18:23
  • I found that `g++ -gdwarf-2 -gstrict-dwarf` emits `DW_AT_MIPS_linkage_name` for namespaces which can be understood by gdb. Probably you can somehow force GHS compiler to emit `DW_AT_MIPS_linkage_name` as well. – ks1322 Feb 21 '18 at 09:59
  • I now think you were correct. It turns out that the Green Hills compiler does emit namespace DIEs, but the tag ID did not match what g++ emits for namespaces. The namespace DIE is a parent of everything within a namespace. When GDB encounters the tag it dosn't know anything about it just ignores it. I was able to patch GDB to automatically convert the GHS namespace tag ID as it reads the DWARF-2. I can now see everything declared within namespaces. – Adam Mar 02 '18 at 18:33