trouble with gdb 5.3, gcc 3.4, mips, dwarf-2

[Paul Koning <pkoning at equallogic dot com>]

Gentlepeople,

I'm not sure how best to attack this so I'm starting here...

I have a slightly modified gdb 5.3 that's given me a bunch of nasty
problems on a MIPS target.  Given what I'm seeing, it's unlikely that
the local changes are the cause (minor tweaks to mips-tdep, plus a
bunch of extensions -- but nothing in the guts of type handling or
symbol table reading).

In the process of trying to look for solutions, I tried building a
current snapshot of gcc for my target.  After some struggles, I have a
build that worked (it doesn't execute -- but at least it links).

Gdb 5.3 acts very strangely as a result.  When I tried to cast a
pointer to a C++ class type, it complained about a parse error.
"ptype" explains why -- gdb didn't recognize the name as a class name,
it took it for a function name.

I reduced it to a simple test case:

class test
{
public:
    int z;
    void foo(int i) 
    {
        z = i;
    }
};

class bar : public test
{
public:
    int m;
    int x;
    bar(int);
    void test(int i) 
    {
        m = i;
    }
};

bar::bar(int i)
{
    x = i;
    m = i*3;
}

int errno;
int exit;
bar *bp;

int main (int, char**)
{
    bp = new bar(16);
}

Compiled with -gdwarf-2, I see this:

(gdb) ptype bar
type = void (bar * const, int)

Compiled with -gstabs+, I get what I expect:

(gdb) ptype bar
type = class bar : public test {
  public:
    int m;
    int x;

    bar & operator=(bar const&);
    bar(bar const&);
    bar(int);
    void test(int);
}

Obviously this could be a gdb problem or a gcc problem.  How can I
tell?  I've poked in both, but only around the edges.

FWIW, the problems that drove me to try this experiment are:

1. For some functions (involving C++ classes with templates and
   multiple inheritance, that may or may not be relevant, I don't know
   yet) breakpoints aren't hit.  Single stepping through the code
   causes nonsensical line numbers to be displayed, jumping wildly
   over several source files as the PC advances by one or two
   instructions. 

2. We see a bunch of symtab vs. psymtab mismatch errors.  The easiest
   way to see it is to issue "maint check-symtabs" on gdb startup; it
   complains bitterly about large quantities of errors (all C++
   mangled names).

Any suggestions?

Thanks,
	paul