This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: trouble with gdb 5.3, gcc 3.4, mips, dwarf-2
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Paul Koning <pkoning at equallogic dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Tue, 22 Apr 2003 18:25:18 -0400
- Subject: Re: trouble with gdb 5.3, gcc 3.4, mips, dwarf-2
- References: <16037.49033.658180.401145@pkoning.dev.equallogic.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