This is the mail archive of the gcc-bugs@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]

debug/2984: File name information is incorrect in debug output



>Number:         2984
>Category:       debug
>Synopsis:       File name information is incorrect in debug output
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon May 28 13:16:01 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     neil@gcc.gnu.org
>Release:        3.0 prerelease, 3.1
>Organization:
>Environment:
Linux x86
>Description:
I've entered this bug under "debug", though I believe the
bug lies in c-lex.c's function cb_file_change, and its
interaction with the global variables and functions of
toplev.c.

Debug output often has the wrong file name, but correct line
number, associated with a line of code.  

Here is an example from Benjamin Kosnik:

#include <cstdio>
#include <iostream>
  
int test01()
{ 
  std::ios_base::sync_with_stdio();
  
  std::printf("1"); // stdout has 1 in in now
  std::cout << "2";
  std::putc('3', stdout); // std::stdout doesn't work here
  std::cout << '4';
  
  return 0;
} 

int main()
{
  test01();
}

Compiling this with -g and the current compiler, and then running
gdb on the resultant execuatable gives:

  std::cout << "2";  // step in on this line

(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /mnt/hd/bliss/src.gcc/libstdc++-v3/testsuite/a.out

std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char>
+>(std::basic_ostream<char, std::char_traits<char> >&, char const*) (
    __out=@0x80ebde0, __s=0x80c8dc2 "2") at include/bits/std_ostream.h:635
Line number 635 out of range; include/bits/std_ostream.h has 283 lines.
>How-To-Repeat:

>Fix:
Probably cb_file_change needs to have a handler for the
case FC_RENAME in addition to FC_ENTER and FC_LEAVE.

However, this is only a guess.
>Release-Note:
>Audit-Trail:
>Unformatted:


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