Re: Pending breakpoints on lines that don't exist

[Joel Brobecker <brobecker@adacore.com>]

> 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