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

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

[Paul Koning]

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

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

[Daniel Jacobowitz]

On Tue, Apr 22, 2003 at 06:17:45PM -0400, Paul Koning wrote:
> 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.

GDB problem, I think, but I'm not quite sure.

The DWARF-2 info probably says that the name of the function is "bar". 
GDB doesn't put this together with other information to establish that
it's actually a method.  So in the global scope we have bar (typedef to
class bar) and bar (function), and GDB happens to pick the function.


> 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. 

The wild jumping I can't explain.  Not hitting breakpoints is about par
for the course right now.  We're working on C++ support, as time
permits.

> 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).

Hmm, I haven't seen this.  I'll have to build a MIPS toolchain and take
a look; it may be a while before I have time.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer