This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Fix internal error on breaking at a multi-locations caller
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: Tom Tromey <tromey at redhat dot com>, gdb-patches at sourceware dot org
- Date: Fri, 1 May 2009 08:47:59 -0700
- Subject: Re: [patch] Fix internal error on breaking at a multi-locations caller
- References: <20090309220736.GA27259@host0.dyn.jankratochvil.net> <m3ljpqq30d.fsf@fleche.redhat.com> <20090428203235.GG31821@adacore.com> <20090501091942.GA8465@host0.dyn.jankratochvil.net>
Hello Jan,
I think Tom must be pretty busy right now :), so here is my take on this.
> info '(gdb)Set Breaks'
> `break'
> When called without any arguments, `break' sets a breakpoint at
> the next instruction to be executed in the selected stack frame
> [...]
>
> Do you refer here to the "selected stack frame" part of the doc?
More importantly: "next instruction"; but yes, the selected stack
frame is also important.
Based on that, "break" in my opinion should be equivalent to "break *PC"
where PC is the current frame's PC. So, I think that the correct way
to fix this is to set the "explicit_pc" flag in the sal. That should
make sure that expand_line_sal_maybe does not, in fact, do any expansion.
I also understand the reason why you think a warning might help,
especially since I had a different intuitive perception of what
the argument-less command was doing. But I think that such a warning
would quickly become more annoying than anything if the user knows
precisely the meaning of his command. What do others think?
Nonetheless, I think we can treat the two issues separately. We can
fix the problem first with a one-liner, and then we can discuss the
idea of a warning if you think it might be useful. Does this sound
reasonable to you?
--
Joel