Pending breakpoints on lines that don't exist

Pending breakpoints on lines that don't exist

[Marc Khouzam]

Hi,

I grabbed the 7.4 branch to make sure Eclipse was ready
for it.  After no longer using the removed command
'maint set python print-stack on'
all our JUnit tests now pass with the new GDB except 
one, which attempts to set a breakpoint on an invalid line.
GDB 7.4 now sets a pending breakpoint on lines that don't
exist.  Is this a regression or a wanted change?
I didn't want to update my tests if this was a regression.

The change is illustrated in the two short sessions below.
Note that this also happens using line 0 (which is what
my JUnit test does).

Thanks

Marc


> gdb.7.3 a.out
GNU gdb (GDB) 7.3.1
(gdb) l
1       int main() { return 0; }
(gdb) l 
Line number 2 out of range; a.cc has 1 lines.
(gdb) b 2
No line 2 in file "a.cc".
(gdb) info b
No breakpoints or watchpoints.


> gdb.7.4 a.out
GNU gdb (GDB) 7.3.91.20120103-cvs
(gdb) l
1       int main() { return 0; }
(gdb) l 
Line number 2 out of range; a.cc has 1 lines.
(gdb) b 2
No line 2 in the current file.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (2) pending.
(gdb) info b
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   <PENDING>  2

Re: Pending breakpoints on lines that don't exist

[Joel Brobecker]

> one, which attempts to set a breakpoint on an invalid line.
> GDB 7.4 now sets a pending breakpoint on lines that don't
> exist.  Is this a regression or a wanted change?
> I didn't want to update my tests if this was a regression.

I am not the author of the change, but I did participate a bit
in its evaluation, so think of my reply as a DNS sending a
"non-authoritative" answer :-).

I think that the idea is that another objfile, typically a shared
library, might appear later on. If that shared library has a file
where this line number is valid, we want the breakpoint to include
this location.  Does that make sense?

I can imagine that it is a bit of a pain to see pending breakpoints
being created for human-entry errors. I tend to make this type of
error regularly, for instance. But it apparently it is only an issue
if you use the "console" interpreter, since "-break-insert" flat out
refuses the breakpoint for me:

    (gdb) 
    -break-insert foo.c:100
    ^error,msg="No line 100 in file \"foo.c\"."

... whereas "break" asks me whether I want to insert a breakpoint:

    (gdb) b foo.c:100
    No line 100 in file "foo.c".
    Make breakpoint pending on future shared library load? (y or [n]) n
    (gdb) b bar.c:100
    No source file named bar.c.
    Make breakpoint pending on future shared library load? (y or [n]) n

In any case, I do not think it's going to be a problem for graphical
front-end users, where I imagine most breakpoints are inserted by
clicking on a specific line of source code (with the exception of
the binary being out of sync with the sources).

And I don't think it's going to be a problem for the console users,
because  the error message seems clear enough to not leave the user
in the dark.

-- 
Joel

Re: Pending breakpoints on lines that don't exist

[Eli Zaretskii]

> Date: Wed, 4 Jan 2012 07:51:28 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: "'gdb@sourceware.org'" <gdb@sourceware.org>
> 
> I think that the idea is that another objfile, typically a shared
> library, might appear later on. If that shared library has a file
> where this line number is valid, we want the breakpoint to include
> this location.  Does that make sense?

Not to me, FWIW.  At the very least, we should have asked a different
question than we ask in the "normal" pending-breakpoint use case.

Re: Pending breakpoints on lines that don't exist

[Joel Brobecker]

> Not to me, FWIW.  At the very least, we should have asked a different
> question than we ask in the "normal" pending-breakpoint use case.

I think we can look at this in the same context as Jan's general
comment: It would be nice if GDB was a little more descriptive of
what is happening, why it is doing what it is doing, propose
explicit recipes for doing other things if this is not what the
user wants, etc. It's a bit like what git often does. For instance
(you do not have to real the whole output, it's just meant to show
helpful git tries to be):

    | % git pull
    | You asked me to pull without telling me which branch you
    | want to merge with, and 'branch.private.merge' in
    | your configuration file does not tell me, either. Please
    | specify which branch you want to use on the command line and
    | try again (e.g. 'git pull <repository> <refspec>').
    | See git-pull(1) for details.
    |
    | If you often merge with the same branch, you may want to
    | use something like the following in your configuration file:
    |
    |     [branch "private"]
    |     remote = <nickname>
    |     merge = <remote-ref>
    |
    |     [remote "<nickname>"]
    |     url = <url>
    |     fetch = <refspec>
    |
    | See git-config(1) for details.

I kind of like the idea.   But in this case, I think it would be
too verbose. Currently, we have:

    (gdb) b foo.c:100
    No line 100 in file "foo.c".
    Make breakpoint pending on future shared library load? (y or [n]) n

I find that the error message is precise and complete. But I do not
want to remove the option of making the breakpoint pending, because
some users might have, in fact, meant what they were doing. And if
the user made an error, do you think they would not understand what
error they made that triggered the question?

-- 
Joel

Re: Pending breakpoints on lines that don't exist

[Eli Zaretskii]

> Date: Wed, 4 Jan 2012 11:16:58 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: marc.khouzam@ericsson.com, gdb@sourceware.org
> 
>     (gdb) b foo.c:100
>     No line 100 in file "foo.c".
>     Make breakpoint pending on future shared library load? (y or [n]) n
> 
> I find that the error message is precise and complete.

Isn't the following at least slightly better?

     (gdb) b foo.c:100
     No line 100 in file "foo.c".
     Make breakpoint pending on future load of shared library
     containing "foo.c" where this line is valid? (y or [n]) n

Re: Pending breakpoints on lines that don't exist

[Joel Brobecker]

> Isn't the following at least slightly better?
> 
>      (gdb) b foo.c:100
>      No line 100 in file "foo.c".
>      Make breakpoint pending on future load of shared library
>      containing "foo.c" where this line is valid? (y or [n]) n

I see what you are trying say. I don't have a strong opinion and
I would not object, but I do prefer the previous phrasing. Also,
I do not see why we would have to treat this case specially.
I think that if we change for this case, we should change for
every type of error. And lastly, one the pragmatic side, this
is going to screw up all the testcases as well as front-end that
might be matching the old output.  This is a weak argument, but
it is true nonetheless.

-- 
Joel

RE: Pending breakpoints on lines that don't exist

[Marc Khouzam]

> From: Joel Brobecker [brobecker@adacore.com]
> Sent: January 3, 2012 10:51 PM
> To: Marc Khouzam
> Cc: 'gdb@sourceware.org'
> Subject: Re: Pending breakpoints on lines that don't exist
> 
> I can imagine that it is a bit of a pain to see pending breakpoints
> being created for human-entry errors. I tend to make this type of
> error regularly, for instance. But it apparently it is only an issue
> if you use the "console" interpreter, since "-break-insert" flat out
> refuses the breakpoint for me:
> 
>     (gdb)
>     -break-insert foo.c:100
>     ^error,msg="No line 100 in file \"foo.c\"."

Just a clarification FYI. In Eclipse, we always use -break-insert -f which
requests pending breakpoints:
(gdb) 
-break-insert -f loopfirst.cc:100
&"No line 100 in file \"loopfirst.cc\".\n"
^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="<PENDING>",pending="loopfirst.cc:100",times="0",original-location="loopfirst.cc:100"}

> ... whereas "break" asks me whether I want to insert a breakpoint:
> 
>     (gdb) b foo.c:100
>     No line 100 in file "foo.c".
>     Make breakpoint pending on future shared library load? (y or [n]) n
>     (gdb) b bar.c:100
>     No source file named bar.c.
>     Make breakpoint pending on future shared library load? (y or [n]) n

To have a consistent behavior between UI and console, we always set:
"-gdb-set breakpoint pending on".
So, for the gdb console in eclipse, the pending breakpoint also gets
set in the case of invalid lines or files.  Although GDB indicates this
clearly:

b foo.c:100
No source file named foo.c.
Breakpoint 7 (foo.c:100) pending.
b 10000
No line 10000 in the current file.
Breakpoint 9 (10000) pending.
 
Note that all this is fine, I just wanted to make sure it was planned.
 
Thanks for explaining things.
 
Marc

Re: Pending breakpoints on lines that don't exist

[Tom Tromey]

>>>>> "Marc" == Marc Khouzam <marc.khouzam@ericsson.com> writes:

Marc> (gdb) b 2
Marc> No line 2 in the current file.
Marc> Make breakpoint pending on future shared library load? (y or [n]) y
Marc> Breakpoint 1 (2) pending.

This is intended, but I wonder whether it would make sense to have
different behavior in the case where the file is implicit.

That is, "b 2" would just give the old error, but "b currentfile.c:2"
would prompt for a pending breakpoint.

The rationale for this would be that, in the implicit filename case, the
user is presumably asking for exactly the current file.

Tom

Re: Pending breakpoints on lines that don't exist

[Pedro Alves]

On 01/04/2012 08:49 PM, Tom Tromey wrote:
>>>>>> "Marc" == Marc Khouzam<marc.khouzam@ericsson.com>  writes:
>
> Marc>  (gdb) b 2
> Marc>  No line 2 in the current file.
> Marc>  Make breakpoint pending on future shared library load? (y or [n]) y
> Marc>  Breakpoint 1 (2) pending.
>
> This is intended, but I wonder whether it would make sense to have
> different behavior in the case where the file is implicit.
>
> That is, "b 2" would just give the old error, but "b currentfile.c:2"
> would prompt for a pending breakpoint.
>
> The rationale for this would be that, in the implicit filename case, the
> user is presumably asking for exactly the current file.

It sounds tempting, but it goes back to guessing user's intentions?

I'm left wondering if the real problem isn't that

 >  No line 2 in the current file.
 >  Make breakpoint pending on future shared library load? (y or [n]) y
 >  Breakpoint 1 (2) pending.

Isn't super clear that "2" doesn't actually mean "line 2 in any file",
but currentfile.c:2.  Or does it not?

Note (debugging gdb):

(top-gdb) b 56
No line 56 in the current file.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 4 (56) pending.
(top-gdb) info breakpoints
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x00000000006a419a in internal_error at ../../src/gdb/utils.c:1046
2       breakpoint     keep y   0x00000000004ccc49 in info_command at ../../src/gdb/cli/cli-cmds.c:229
         silent
         return
4       breakpoint     keep y   <PENDING>          56
(top-gdb)

When read this, I go "where will breakpoint 4 resolve again?".  It feels like gdb should show
the (normalized) spec back to the user.  "What" isn't exactly that.

I find myself confused like that with e.g., `*' breakpoints.  As in,
was that a * breakpoint I set there, or not?:

(top-gdb) b *main
Breakpoint 5 at 0x455314: file ../../src/gdb/gdb.c, line 26.
(top-gdb) info breakpoints 5
Num     Type           Disp Enb Address            What
5       breakpoint     keep y   0x0000000000455314 in main at ../../src/gdb/gdb.c:26
(top-gdb) b main
Breakpoint 6 at 0x455323: file ../../src/gdb/gdb.c, line 29.
(top-gdb) info breakpoints 5-6
Num     Type           Disp Enb Address            What
5       breakpoint     keep y   0x0000000000455314 in main at ../../src/gdb/gdb.c:26
6       breakpoint     keep y   0x0000000000455323 in main at ../../src/gdb/gdb.c:29

-- 
Pedro Alves

Re: Pending breakpoints on lines that don't exist

[Richard Guenther]

[sorry for breaking threading, I'm not subscribed]

<quote>
> Not to me, FWIW.  At the very least, we should have asked a different
> question than we ask in the "normal" pending-breakpoint use case.
...
I kind of like the idea.   But in this case, I think it would be
too verbose. Currently, we have:

    (gdb) b foo.c:100
    No line 100 in file "foo.c".
    Make breakpoint pending on future shared library load? (y or [n]) n

I find that the error message is precise and complete. But I do not
want to remove the option of making the breakpoint pending, because
some users might have, in fact, meant what they were doing. And if
the user made an error, do you think they would not understand what
error they made that triggered the question?
</quote>

OTOH what mostly happens to me is:

> gdb ./cc1
GNU gdb (GDB) SUSE (7.3-98.1)
...
(gdb) b expr.c:10850
No line 10850 in file "/space/rguenther/src/svn/trunk/libcpp/expr.c".

because I meant /space/rguenther/src/svn/trunk/gcc/expr.c!  Now
getting the pending breakpoing seems to be even worse.  I'd
expect sth like

(gdb) b expr.c:10850
No line 10850 in file "/space/rguenther/src/svn/trunk/libcpp/expr.c"
Use alternate source file /space/rguenther/src/svn/trunk/gcc/expr.c? (y or 
[n])

it's especially bad that gdb does not recognize

(gdb) b gcc/expr.c:10850

but requires a full path (bah).

No idea if this improved for gdb 7.4 though.

Richard.

Re: Pending breakpoints on lines that don't exist

[Richard Guenther]

On Wed, 4 Jan 2012, Richard Guenther wrote:

> 
> [sorry for breaking threading, I'm not subscribed]
> 
> <quote>
> > Not to me, FWIW.  At the very least, we should have asked a different
> > question than we ask in the "normal" pending-breakpoint use case.
> ...
> I kind of like the idea.   But in this case, I think it would be
> too verbose. Currently, we have:
> 
>     (gdb) b foo.c:100
>     No line 100 in file "foo.c".
>     Make breakpoint pending on future shared library load? (y or [n]) n
> 
> I find that the error message is precise and complete. But I do not
> want to remove the option of making the breakpoint pending, because
> some users might have, in fact, meant what they were doing. And if
> the user made an error, do you think they would not understand what
> error they made that triggered the question?
> </quote>
> 
> OTOH what mostly happens to me is:
> 
> > gdb ./cc1
> GNU gdb (GDB) SUSE (7.3-98.1)
> ...
> (gdb) b expr.c:10850
> No line 10850 in file "/space/rguenther/src/svn/trunk/libcpp/expr.c".
> 
> because I meant /space/rguenther/src/svn/trunk/gcc/expr.c!  Now
> getting the pending breakpoing seems to be even worse.  I'd
> expect sth like
> 
> (gdb) b expr.c:10850
> No line 10850 in file "/space/rguenther/src/svn/trunk/libcpp/expr.c"
> Use alternate source file /space/rguenther/src/svn/trunk/gcc/expr.c? (y or 
> [n])
> 
> it's especially bad that gdb does not recognize
> 
> (gdb) b gcc/expr.c:10850

Oh, and with this gdb 7.3 (Fedora) already does

(gdb) b gcc/expr.c:10850
No source file named gcc/expr.c.
Make breakpoint pending on future shared library load? (y or [n]) n

Richard.

Re: Pending breakpoints on lines that don't exist

[Tom Tromey]

>>>>> "Richard" == Richard Guenther <rguenther@suse.de> writes:

Richard> (gdb) b expr.c:10850
Richard> No line 10850 in file "/space/rguenther/src/svn/trunk/libcpp/expr.c".

Richard> because I meant /space/rguenther/src/svn/trunk/gcc/expr.c!  Now
Richard> getting the pending breakpoing seems to be even worse.  I'd
Richard> expect sth like
[...]

In 7.4, a linespec like "expr.c:10850" will match line 10850 in all
files named expr.c.

E.g., from the test suite:

(gdb) b thefile.cc:14
Breakpoint 1 at 0x400592: thefile.cc:14. (2 locations)
(gdb) info b
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   <MULTIPLE>         
1.1                         y     0x0000000000400592 in n(int) 
                                                   at ../../../archer/gdb/testsuite/gdb.linespec/base/two/thefile.cc:14
1.2                         y     0x0000000000400556 in m(int) 
                                                   at ../../../archer/gdb/testsuite/gdb.linespec/base/one/thefile.cc:14


This breakpoint got locations in two different files, both named 'thefile.cc'.

The rationale behind this is that gdb should not guess what you meant.


The right thing also happens if one "thefile.cc" has the indicated line
but the other does not.

Richard> it's especially bad that gdb does not recognize
Richard> (gdb) b gcc/expr.c:10850
Richard> but requires a full path (bah).

Yeah, this is still a problem.  I intend to fix it at some point, but
it is too late for 7.4.

I think what makes sense here is to just do the obvious check of the
user-supplied name against the final components of the file names.

Tom