This is the mail archive of the gcc-prs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: debug/1819: severe problems debugging c++-code (libstdc++)


The following reply was made to PR debug/1819; it has been noted by GNATS.

From: Phil Edwards <pedwards@disaster.jaj.com>
To: schmid@snake.iap.physik.tu-darmstadt.de
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: debug/1819: severe problems debugging c++-code (libstdc++)
Date: Sun, 4 Feb 2001 14:42:39 -0500

 On Wed, Jan 31, 2001 at 05:27:40PM +0100, schmid@snake.iap.physik.tu-darmstadt.de wrote:
 > 
 > >Number:         1819
 > >Category:       debug
 > >Synopsis:       severe problems debugging c++-code (libstdc++)
 > >Confidential:   no
 > >Severity:       critical
 > >Priority:       medium
 > >Responsible:    unassigned
 > >State:          open
 > >Class:          sw-bug
 > >Submitter-Id:   net
 > >Arrival-Date:   Wed Jan 31 08:36:04 PST 2001
 > >Closed-Date:
 > >Last-Modified:
 > >Originator:     Peter Schmid
 > >Release:        2.97 20010129 (experimental)
 > >Description:
 > Running the following program tp generates a segmentation
 > fault. If I set a breakpoint at the line std::cout << " "; of the
 > program tp and set into that function the debugger messages are
 > unusable. First the line number is out of bounce; the debugger
 > searche for a line with the number 635 instead of the correct line
 > number 213.
 
 This has been reported before, see the 7 messages beginning with
 <http://gcc.gnu.org/ml/gcc-bugs/2001-01/msg00169.html>.  It seems to occur
 when a header file #includes one of the .tcc files; the line numbers inside
 the .tcc file aren't counted from scratch.  (I think.)
 
 I can confirm other parts of this PR as well, but not all of it.
 
 
 > Secondly the type of __cout, basic_ostream<_CharT,
 > _Traits>&, is not detected.
 
 I don't know about that one.
 
 > After single stepping until somehow the
 > function   _S_pad_char is called, I encounter that the debugger jumps
 > up and down inside the body of the function as if the were a loop,
 > but there is not.
 
 This bit me the other day, trying to step through libstdc++ functions.
 Using 'n' would go from line N to N+1 to N to N+1 to N to N+30.  Really odd.
 
 > I tryed different versions of the gdb. All showed
 > the same behaviour. 
 
 All I've tried is CVS gdb, since that's the only one which properly supports
 CVS g++'s name mangling.
 
 
 Phil
 

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]