This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Pending breakpoints on lines that don't exist
- From: Richard Guenther <rguenther at suse dot de>
- To: gdb at sourceware dot org
- Cc: brobecker at adacore dot com
- Date: Wed, 4 Jan 2012 15:28:40 +0100 (CET)
- Subject: Re: Pending breakpoints on lines that don't exist
[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.