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

[Daniel Jacobowitz <drow@mvista.com>]

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