Re: Pending breakpoints on lines that don't exist

[Joel Brobecker <brobecker at adacore dot com>]

> 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