This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
Re: c++/1245: cp-support.c:332: internal-error: cp_entire_prefix_len
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 19 Jun 2003 16:58:01 -0000
- Subject: Re: c++/1245: cp-support.c:332: internal-error: cp_entire_prefix_len
- Reply-to: Daniel Jacobowitz <drow at mvista dot com>
The following reply was made to PR c++/1245; it has been noted by GNATS.
From: Daniel Jacobowitz <drow@mvista.com>
To: Stephane.Carrez@nerim.fr
Cc: gdb-gnats@sources.redhat.com, carlton@bactrian.org
Subject: Re: c++/1245: cp-support.c:332: internal-error: cp_entire_prefix_len
Date: Thu, 19 Jun 2003 12:49:04 -0400
On Wed, Jun 18, 2003 at 08:56:47PM -0000, Stephane.Carrez@nerim.fr wrote:
>
> >Number: 1245
> >Category: c++
> >Synopsis: cp-support.c:332: internal-error: cp_entire_prefix_len
> >Confidential: no
> >Severity: critical
> >Priority: high
> >Responsible: unassigned
> >State: open
> >Class: sw-bug
> >Submitter-Id: net
> >Arrival-Date: Wed Jun 18 20:58:01 UTC 2003
> >Closed-Date:
> >Last-Modified:
> >Originator: Stephane Carrez
> >Release: 2003-06-17-cvs
> >Organization:
> >Environment:
> i686-pc-linux-gnu
> >Description:
> gdb crashes when loading the symbols of a C++ program.
> (it was working very well before, ie gdb 5.3).
>
> It crashes when it sees the symbol:
>
> __lt__H3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b1i0_RCt12basic_string3ZX01ZX11ZX21T0_b
>
> which corresponds to:
>
> bool operator<<char, string_char_traits<char>, __default_alloc_template<true, 0> >(basic_string<char, string_char_traits<char>, __default_alloc_template<true, 0> > const &, basic_string<char, string_char_traits<char>, __default_alloc_template<true, 0> > const &)
>
> The original C++ program was compiled by gcc 2.95.4
> (on debian). The '<' operator is from the STL.
>
> GNU gdb 2003-06-17-cvs
> Copyright 2003 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "i686-pc-linux-gnu"...
> (gdb) b main
> cp-support.c:332: internal-error: cp_entire_prefix_len: Assertion `name[current_len] == ':'' failed.
> A problem internal to GDB has been detected. Further
> debugging may prove unreliable.
> Quit this debugging session? (y or n) n
> Create a core file of GDB? (y or n) n
> (gdb) quit
>
> >How-To-Repeat:
> The gdb-bug.cpp just creates the faulty symbol. It must
> be compiled by c++ compiler (2.95 or 3.3).
>
> g++ -o gdb-bug -g gdb-bug.cpp
> gdb gdb-bug
> (gdb) b main
>
>
> >Fix:
> David,
>
> the problem is due to the fact that the operator function
> is '<' and not '<<'. The second '<' is the beginning of
> a template instantiation. This is wierd because you have
> no way (to my knowledge) to distinguish between:
>
> operator < <template instance>
> operator <<
>
> Since the second < is eat by the operator processing,
> we come up with a wrong result. Ideally, the demangler
> should insert a space after the operator <
Hm, we might be able to handle this - at least for some cases.
"operator <<" should always be followed by either a template
instantiation or an argument list. If we see "operator <<<"
or "operator "<< " then we have operator <<; template args will not
start with a space or an angle bracket.
"operator <<(" is actually ambiguous:
operator <<(char)1>(foo, bar) is operator <
operator <<(char, bar) is operator <<
However, we could take advantage of the fact that both operator < and
operator << are binary operators, and scan for a toplevel comma
following that parenthesis. I think that would suffice.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer