[PATCH] Fix problems with finishing a dummy function call on simulators.

[Luis Machado <lgustavo at codesourcery dot com>]

This is in line with what was done by Joel's patch here:

https://sourceware.org/ml/gdb-patches/2014-11/msg00478.html

And it also answers Pedro's question about whether this is specific to SPARC
QEMU or not.  This indeed seems to affect multiple QEMU targets and also other
simulators (proprietary).

I ran into this weird issue of not being able to "finish" an inferior function
call. It looks as if the program is running away, but it really is stuck
somewhere.  "finish" still works fine for regular functions not called manually
by GDB.

I tracked this failure down to GDB having both a bp_call_dummy and bp_finish in
its breakpoint list. As a result of one not being considered permanent and the
other considered permanent, GDB will not issue a Z packet to force the insertion
of that location's breakpoint, confusing the simulator that does not know how
to deal properly with these permanent breakpoints that GDB inserted beforehand.

The attached patch fixes this, though i'm inclined to say we could probably
check if both bp_call_dummy and bp_finish are present and force the
insertion of that location's breakpoint. It isn't clear to me where exactly that
check would go or if it would be cleaner than checking that information in
the same function Joel used.

I see no regressions on x86-64 and it fixes a bunch of failures for simulator
targets we use (MIPS and PowerPC to name two).

gdb/ChangeLog:

2015-06-09  Luis Machado  <lgustavo@codesourcery.com>

	* breakpoint.c (bp_loc_is_permanent): Return 0 for bp_finish
	as well.
---
 gdb/breakpoint.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c
index 657c58e..eb3df02 100644
--- a/gdb/breakpoint.c
+++ b/gdb/breakpoint.c
@@ -8984,8 +8984,16 @@ bp_loc_is_permanent (struct bp_location *loc)
      0x02 while interrupts disabled, Error state) instead of reporting
      a SIGTRAP.  QEMU should probably be fixed, but in the interest of
      compatibility with versions that behave this way, we always consider
-     bp_call_dummy breakpoint locations as non-permanent.  */
-  if (loc->owner->type == bp_call_dummy)
+     bp_call_dummy breakpoint locations as non-permanent.
+
+     Another situation arises when we have a bp_call_dummy breakpoint inserted
+     and then the user issues a finish, triggering GDB to create a bp_finish
+     breakpoint to handle the return from the inferior function call.  When
+     both bp_call_dummy and bp_finish breakpoints are present, GDB will not
+     force the insertion of these locations, triggering, once again, the
+     problem described above.  Therefore we check for bp_finish here as
+     well.  */
+  if (loc->owner->type == bp_call_dummy || loc->owner->type == bp_finish)
     return 0;
 
   cleanup = save_current_space_and_thread ();
-- 
1.9.1