GDB doesn't show the correct line

GDB doesn't show the correct line

[Otto Wyss]

Since a few days GDB (6.1-debian) offsets the shown line by about 3
lines. when I set a breakpoint at a function name of a class (C++) it
stops and shows the line 3 more down. When I now step through (next)
always the next line is shown, sometimes even empty lines. It seems the
correct statements  were processed. Is this a known problem and is there
a workaround?

O. Wyss

-- 
See a huge pile of work at "http://wyodesktop.sourceforge.net/"

Re: GDB doesn't show the correct line

[Daniel Jacobowitz]

On Sun, Jun 20, 2004 at 09:24:48PM +0200, Otto Wyss wrote:
> Since a few days GDB (6.1-debian) offsets the shown line by about 3
> lines. when I set a breakpoint at a function name of a class (C++) it
> stops and shows the line 3 more down. When I now step through (next)
> always the next line is shown, sometimes even empty lines. It seems the
> correct statements  were processed. Is this a known problem and is there
> a workaround?

Not a known problem - test case?

Usually this means you've confused GDB about what version of a source
file it should be opening.

-- 
Daniel Jacobowitz

Re: GDB doesn't show the correct line

[Otto Wyss]

Daniel Jacobowitz wrote:
> 
> On Sun, Jun 20, 2004 at 09:24:48PM +0200, Otto Wyss wrote:
> > Since a few days GDB (6.1-debian) offsets the shown line by about 3
> > lines. when I set a breakpoint at a function name of a class (C++) it
> > stops and shows the line 3 more down. When I now step through (next)
> 
> Not a known problem - test case?
> 
My full source is here
"http://cvs.sourceforge.net/viewcvs.py/wyodesktop/wyoDesktop/loginapp/src/app.cpp?view=markup"
but it's probably not usable as a test case. The 3 line offset is from
the first function call "App::OnInit".

> Usually this means you've confused GDB about what version of a source
> file it should be opening.
> 
It's definitely not my source since I've built my app and all the
wxWidgets library again. Also I just tried another of my apps (with lots
of wxWidgets functions) and this behaves correctly. Well that means GDB
works correct except in one case.

I can only speculate that it's because of one of the standard headers
which are unique to this program. But they are from an ordinary
Debian/sarge system. How can I detect further where the offset is introduced?

O. Wyss

-- 
See a huge pile of work at "http://wyodesktop.sourceforge.net/"

Re: GDB doesn't show the correct line

[Daniel Jacobowitz]

On Mon, Jun 21, 2004 at 07:55:59PM +0200, Otto Wyss wrote:
> Daniel Jacobowitz wrote:
> > 
> > On Sun, Jun 20, 2004 at 09:24:48PM +0200, Otto Wyss wrote:
> > > Since a few days GDB (6.1-debian) offsets the shown line by about 3
> > > lines. when I set a breakpoint at a function name of a class (C++) it
> > > stops and shows the line 3 more down. When I now step through (next)
> > 
> > Not a known problem - test case?
> > 
> My full source is here
> "http://cvs.sourceforge.net/viewcvs.py/wyodesktop/wyoDesktop/loginapp/src/app.cpp?view=markup"
> but it's probably not usable as a test case. The 3 line offset is from
> the first function call "App::OnInit".
> 
> > Usually this means you've confused GDB about what version of a source
> > file it should be opening.
> > 
> It's definitely not my source since I've built my app and all the
> wxWidgets library again. Also I just tried another of my apps (with lots
> of wxWidgets functions) and this behaves correctly. Well that means GDB
> works correct except in one case.
> 
> I can only speculate that it's because of one of the standard headers
> which are unique to this program. But they are from an ordinary
> Debian/sarge system. How can I detect further where the offset is introduced?

The only things that I can recommend:
  - Look at the preprocessor output (gcc -E).  See if there are missing
    #line directives (usually just "# <num>" in preprocessor output).
    The syntax of these things is really hard to read.
  - Look at the debug info with readelf -wl and compare it to the
    object code.

It sounds like it is more likely to be a problem with GCC's output than
GDB's parsing.

-- 
Daniel Jacobowitz

Re: GDB doesn't show the correct line

[Otto Wyss]

Daniel Jacobowitz wrote:
> 
> > I can only speculate that it's because of one of the standard headers
> > which are unique to this program. But they are from an ordinary
> > Debian/sarge system. How can I detect further where the offset is introduced?
> 
> The only things that I can recommend:
>   - Look at the preprocessor output (gcc -E).  See if there are missing
>     #line directives (usually just "# <num>" in preprocessor output).
>     The syntax of these things is really hard to read.
>   - Look at the debug info with readelf -wl and compare it to the
>     object code.
> 
Not a very nice prospect, I guess I won't be able to detect anything
useful within resonable time :-(

> It sounds like it is more likely to be a problem with GCC's output than
> GDB's parsing.
> 
I just inserted a syntax error in my source, at least GCC reports the
correct line number.

Can't this line number problem somehow detected within GDB? Sorry if I
ask this as someone without knowing any internals but IMO this would be
the best solution. My app is now working so I'm not in a hurry but a
good debugger is _essential_  for any development.

O. Wyss

-- 
See a huge pile of work at "http://wyodesktop.sourceforge.net/"

Re: GDB doesn't show the correct line

[Daniel Jacobowitz]

On Mon, Jun 21, 2004 at 08:15:10PM +0200, Otto Wyss wrote:
> Daniel Jacobowitz wrote:
> > 
> > > I can only speculate that it's because of one of the standard headers
> > > which are unique to this program. But they are from an ordinary
> > > Debian/sarge system. How can I detect further where the offset is introduced?
> > 
> > The only things that I can recommend:
> >   - Look at the preprocessor output (gcc -E).  See if there are missing
> >     #line directives (usually just "# <num>" in preprocessor output).
> >     The syntax of these things is really hard to read.
> >   - Look at the debug info with readelf -wl and compare it to the
> >     object code.
> > 
> Not a very nice prospect, I guess I won't be able to detect anything
> useful within resonable time :-(
> 
> > It sounds like it is more likely to be a problem with GCC's output than
> > GDB's parsing.
> > 
> I just inserted a syntax error in my source, at least GCC reports the
> correct line number.
> 
> Can't this line number problem somehow detected within GDB? Sorry if I
> ask this as someone without knowing any internals but IMO this would be
> the best solution. My app is now working so I'm not in a hurry but a
> good debugger is _essential_  for any development.

Not without knowing what the problem _is_ - which we don't until
someone does the analysis I described above.

-- 
Daniel Jacobowitz

Re: GDB doesn't show the correct line

[Tarjei Knapstad]

On Sun, 2004-06-20 at 22:29, Daniel Jacobowitz wrote:
> On Sun, Jun 20, 2004 at 09:24:48PM +0200, Otto Wyss wrote:
> > Since a few days GDB (6.1-debian) offsets the shown line by about 3
> > lines. when I set a breakpoint at a function name of a class (C++) it
> > stops and shows the line 3 more down. When I now step through (next)
> > always the next line is shown, sometimes even empty lines. It seems the
> > correct statements  were processed. Is this a known problem and is there
> > a workaround?
> 
> Not a known problem - test case?
> 
> Usually this means you've confused GDB about what version of a source
> file it should be opening.

Yes, this sounds suspiciously like what I see whenever I edit some
source and then forget to recompile before running gdb again.

Are you absolutely certain that you've rebuilt anything that needs to be
after a source edit? If you do a complete rebuild (make clean; make) do
you still have this problem? If not then there's some dependencies
missing in your build system which results in some objects not being
rebuilt after a source edit when they really should be.

--
Tarjei 

Re: GDB doesn't show the correct line

[Daniel Jacobowitz]

On Mon, Jun 21, 2004 at 08:15:10PM +0200, Otto Wyss wrote:
> Daniel Jacobowitz wrote:
> > 
> > > I can only speculate that it's because of one of the standard headers
> > > which are unique to this program. But they are from an ordinary
> > > Debian/sarge system. How can I detect further where the offset is introduced?
> > 
> > The only things that I can recommend:
> >   - Look at the preprocessor output (gcc -E).  See if there are missing
> >     #line directives (usually just "# <num>" in preprocessor output).
> >     The syntax of these things is really hard to read.
> >   - Look at the debug info with readelf -wl and compare it to the
> >     object code.
> > 
> Not a very nice prospect, I guess I won't be able to detect anything
> useful within resonable time :-(
> 
> > It sounds like it is more likely to be a problem with GCC's output than
> > GDB's parsing.
> > 
> I just inserted a syntax error in my source, at least GCC reports the
> correct line number.
> 
> Can't this line number problem somehow detected within GDB? Sorry if I
> ask this as someone without knowing any internals but IMO this would be
> the best solution. My app is now working so I'm not in a hurry but a
> good debugger is _essential_  for any development.

It's no one's fault, I think.  I tracked down the problem.  You have
mixed newline conventions in the file: mostly "\n" as a line separator,
but in some places just "\r".  GCC treats this as a line break for
legacy reasons (MacOS).  'less' doesn't, which really confused me while
trying to debug the problem.  GDB doesn't, either.

Should GDB?  I have no idea.  But it's easiest to just fix the source
file to be consistent.

-- 
Daniel Jacobowitz

Re: GDB doesn't show the correct line

[Otto Wyss]

Daniel Jacobowitz wrote:
> 
> On Mon, Jun 21, 2004 at 08:15:10PM +0200, Otto Wyss wrote:
> > Daniel Jacobowitz wrote:
> > >
> > Can't this line number problem somehow detected within GDB? Sorry if I
> > ask this as someone without knowing any internals but IMO this would be
> > the best solution. My app is now working so I'm not in a hurry but a
> > good debugger is _essential_  for any development.
> 
> It's no one's fault, I think.  I tracked down the problem.  You have
> mixed newline conventions in the file: mostly "\n" as a line separator,
> but in some places just "\r".  GCC treats this as a line break for
> legacy reasons (MacOS).  'less' doesn't, which really confused me while
> trying to debug the problem.  GDB doesn't, either.
> 
> Should GDB?  I have no idea.  But it's easiest to just fix the source
> file to be consistent.
> 
Of course I check all my sources but I fear it's in some header file
(most probably wxWidgets). I've never edited any of my sources on the Mac.

IMO it would be best if GDB would handle line separators equally as GCC.
So the behaviour would be consistent an easier understandable by the user.

O. Wyss

-- 
Development of frame buffer drivers: http://linux-fbdev.sf.net
Sample code snippets for wxWidgets: http://wxcode.sf.net
How to build well-designed applications: http://wxguide.sf.net
Desktop with a consistent look and feel: http://wyodesktop.sf.net

Re: GDB doesn't show the correct line

[Daniel Jacobowitz]

On Sat, Nov 13, 2004 at 09:50:00PM +0100, Otto Wyss wrote:
> Daniel Jacobowitz wrote:
> > 
> > On Mon, Jun 21, 2004 at 08:15:10PM +0200, Otto Wyss wrote:
> > > Daniel Jacobowitz wrote:
> > > >
> > > Can't this line number problem somehow detected within GDB? Sorry if I
> > > ask this as someone without knowing any internals but IMO this would be
> > > the best solution. My app is now working so I'm not in a hurry but a
> > > good debugger is _essential_  for any development.
> > 
> > It's no one's fault, I think.  I tracked down the problem.  You have
> > mixed newline conventions in the file: mostly "\n" as a line separator,
> > but in some places just "\r".  GCC treats this as a line break for
> > legacy reasons (MacOS).  'less' doesn't, which really confused me while
> > trying to debug the problem.  GDB doesn't, either.
> > 
> > Should GDB?  I have no idea.  But it's easiest to just fix the source
> > file to be consistent.
> > 
> Of course I check all my sources but I fear it's in some header file
> (most probably wxWidgets). I've never edited any of my sources on the Mac.

No, it's in app.cpp.  Any decent text viewer will show you where -
"less" for instance.  Look for the two #include lines which it doesn't
wrap correctly.

> IMO it would be best if GDB would handle line separators equally as GCC.
> So the behaviour would be consistent an easier understandable by the user.

I think this behavior should be removed from GCC, personally.  But GCC
isn't the only compiler used by GDB; if you play this sort of game with
line endings, you're going to lose on some combination anyway.

-- 
Daniel Jacobowitz

Re: GDB doesn't show the correct line

[Eli Zaretskii]

> Date: Sat, 13 Nov 2004 15:18:03 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb@sources.redhat.com
> 
> It's no one's fault, I think.  I tracked down the problem.  You have
> mixed newline conventions in the file: mostly "\n" as a line separator,
> but in some places just "\r".  GCC treats this as a line break for
> legacy reasons (MacOS).  'less' doesn't, which really confused me while
> trying to debug the problem.  GDB doesn't, either.
> 
> Should GDB?  I have no idea.

As of today, GDB should treat \r\n (a.k.a. CR-LF) line endings
correctly, but not sole \r.  Perhaps we should amend that code to
treat sole CRs as well.

> But it's easiest to just fix the source file to be consistent.

Indeed.

Re: GDB doesn't show the correct line

[Daniel Jacobowitz]

On Sat, Nov 13, 2004 at 11:40:40PM +0200, Eli Zaretskii wrote:
> > Date: Sat, 13 Nov 2004 15:18:03 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: gdb@sources.redhat.com
> > 
> > It's no one's fault, I think.  I tracked down the problem.  You have
> > mixed newline conventions in the file: mostly "\n" as a line separator,
> > but in some places just "\r".  GCC treats this as a line break for
> > legacy reasons (MacOS).  'less' doesn't, which really confused me while
> > trying to debug the problem.  GDB doesn't, either.
> > 
> > Should GDB?  I have no idea.
> 
> As of today, GDB should treat \r\n (a.k.a. CR-LF) line endings
> correctly, but not sole \r.  Perhaps we should amend that code to
> treat sole CRs as well.

I'm not inclined to do this.  If we're already in the presence of mixed
line endings, who's to say we aren't mixing \r, \n, and \r\n?

Hmm.  Eli, how would you feel about complaining about this situation? 
If we read in a file and discover more than one kind of line ending,
we're likely to get confused.

> > But it's easiest to just fix the source file to be consistent.
> 
> Indeed.

Which is why I prefer this solution :-)

-- 
Daniel Jacobowitz

Re: GDB doesn't show the correct line

[Otto Wyss]

Daniel Jacobowitz wrote:
> 
> On Sat, Nov 13, 2004 at 09:50:00PM +0100, Otto Wyss wrote:
> > >
> > IMO it would be best if GDB would handle line separators equally as GCC.
> > So the behaviour would be consistent an easier understandable by the user.
> 
> I think this behavior should be removed from GCC, personally.  But GCC
> isn't the only compiler used by GDB; if you play this sort of game with
> line endings, you're going to lose on some combination anyway.
> 
Unfortunately we all don't live in an ideal world and have to care for
some wrong situations. A good product would at least complain if it
detects a situation which it can't handle correct. Therefore IMO GDB
should at least give a warning if different line endings are discovered.

O. Wyss

-- 
Development of frame buffer drivers: http://linux-fbdev.sf.net
Sample code snippets for wxWidgets: http://wxcode.sf.net
How to build well-designed applications: http://wxguide.sf.net
Desktop with a consistent look and feel: http://wyodesktop.sf.net

Re: GDB doesn't show the correct line

[Eli Zaretskii]

> Date: Sat, 13 Nov 2004 16:46:12 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: otto.wyss@orpatec.ch, gdb@sources.redhat.com
> 
> Hmm.  Eli, how would you feel about complaining about this situation? 

You mean, print some kind of warning?  Yes, that would be appropriate
as well, I think.

Re: GDB doesn't show the correct line

[Tom Tromey]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

>> As of today, GDB should treat \r\n (a.k.a. CR-LF) line endings
>> correctly, but not sole \r.  Perhaps we should amend that code to
>> treat sole CRs as well.

Daniel> I'm not inclined to do this.  If we're already in the presence of mixed
Daniel> line endings, who's to say we aren't mixing \r, \n, and \r\n?

Java defines \r, \r\n, and \n as valid line endings.  I've seen actual
java source files in the wild that mix two of the three (and maybe all
three, I forget).  What this means is that either gdb should match
java :-), or the definition needs to be language-specific.

Tom

Re: GDB doesn't show the correct line

[Eli Zaretskii]

> Cc: otto.wyss@orpatec.ch, gdb@sources.redhat.com
> From: Tom Tromey <tromey@redhat.com>
> Date: 13 Nov 2004 22:28:38 -0700
> 
> Java defines \r, \r\n, and \n as valid line endings.  I've seen actual
> java source files in the wild that mix two of the three (and maybe all
> three, I forget).

What does Java do when it sees \r\n -- does that count as one line or
two?  (I assume there are some utilities in the JDK that number
lines.)  What does the Java compiler do in that case wrt line numbers?

This is important for GDB because we need to count lines exactly like
the compiler does.  If we support sole \r even in mixed EOL-format
files, then it is not clear what to do with the \r\n case: is it a
single DOS-style line or one Mac-style and one Unix-style line?

Re: GDB doesn't show the correct line

[Andreas Schwab]

"Eli Zaretskii" <eliz@gnu.org> writes:

> This is important for GDB because we need to count lines exactly like
> the compiler does.  If we support sole \r even in mixed EOL-format
> files, then it is not clear what to do with the \r\n case: is it a
> single DOS-style line or one Mac-style and one Unix-style line?

IMHO the longest match should count.  But the more problematic cases would
be \n\r or \r\r\n.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: GDB doesn't show the correct line

[Eli Zaretskii]

> Cc: tromey@redhat.com, drow@false.org, otto.wyss@orpatec.ch,
> 	gdb@sources.redhat.com
> From: Andreas Schwab <schwab@suse.de>
> Date: Sun, 14 Nov 2004 22:24:28 +0100
> 
> But the more problematic cases would be \n\r or \r\r\n.

Why are these more problematic?

Re: GDB doesn't show the correct line

[Felix Lee]

"Eli Zaretskii" <eliz@gnu.org>:
> What does Java do when it sees \r\n -- does that count as one line or
> two?  (I assume there are some utilities in the JDK that number
> lines.)  What does the Java compiler do in that case wrt line numbers?

"\r\n" is one line, "\r" is one line, "\n" is one line.
"\n\r" is two lines, "\r\r" is two lines, "\r\r\n" is two lines,
"\r\n\r" is two lines, etc.
http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc.html#231571
--

Re: GDB doesn't show the correct line

[Andreas Schwab]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> Cc: tromey@redhat.com, drow@false.org, otto.wyss@orpatec.ch,
>> 	gdb@sources.redhat.com
>> From: Andreas Schwab <schwab@suse.de>
>> Date: Sun, 14 Nov 2004 22:24:28 +0100
>> 
>> But the more problematic cases would be \n\r or \r\r\n.
>
> Why are these more problematic?

Because they look like non-canonical line endings, but can be interpreted
as two line endings when using a strict interpretation.  The first one
could be a Unix newline followed by a Mac newline, or a non-canonical DOS
newline (should non-canonical DOS newlines be recognized?).  The second
one could be a Mac newline followed by a DOS newline, or a spurious CR
followed by a DOS newline (should spurious CRs be ignored?).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: GDB doesn't show the correct line

[Eli Zaretskii]

> From: Felix Lee <felix.1@canids.net>
> Cc: tromey@redhat.com, drow@false.org, otto.wyss@orpatec.ch,
> 	gdb@sources.redhat.com
> Date: Sun, 14 Nov 2004 14:39:18 -0800
> 
> "\r\n" is one line, "\r" is one line, "\n" is one line.
> "\n\r" is two lines, "\r\r" is two lines, "\r\r\n" is two lines,
> "\r\n\r" is two lines, etc.
> http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc.html#231571

Thanks.

This should be doable, I think.

Re: GDB doesn't show the correct line

[Eli Zaretskii]

> Cc: tromey@redhat.com, drow@false.org, otto.wyss@orpatec.ch,
> 	gdb@sources.redhat.com
> From: Andreas Schwab <schwab@suse.de>
> Date: Mon, 15 Nov 2004 00:13:07 +0100
> 
> Because they look like non-canonical line endings, but can be interpreted
> as two line endings when using a strict interpretation.  The first one
> could be a Unix newline followed by a Mac newline, or a non-canonical DOS
> newline (should non-canonical DOS newlines be recognized?).  The second
> one could be a Mac newline followed by a DOS newline, or a spurious CR
> followed by a DOS newline (should spurious CRs be ignored?).

If we support \r Mac-style newlines, then (see Felix's message in this
thread), we cannot support non-canonical line-endings and we cannot
ignore spurious CRs.