Fix problems with finishing a dummy function call on simulators.

  On 07/06/2015 01:15 PM, Pedro Alves wrote:
> On 07/06/2015 04:33 PM, Luis Machado wrote:
>
>> I'll take a look at it. I suppose this will block the branching?
>
> I think so, or at least the release.  Broken infcalls seems
> pretty nasty.
>
>> Then again, simply reverting this will still have bad results with some
>> simulators.
>
> True.  Might be the fix is simple though.  I'm seeing this:
>
> (gdb) PASS: gdb.base/shlib-call.exp: step out of shr2 to main (stopped in shr2 epilogue)
> step
> main () at /home/pedro/gdb/mygit/build/../src/gdb/testsuite/gdb.base/shmain.c:37
> 37        g = mainshr1(g);
> (gdb) PASS: gdb.base/shlib-call.exp: step out of shr2 epilogue to main
> print mainshr1(1)
>
> Program received signal SIGSEGV, Segmentation fault.
> mainshr1 (g=1) at /home/pedro/gdb/mygit/build/../src/gdb/testsuite/gdb.base/shmain.c:29
> 29      }
> The program being debugged was signaled while in a function called from GDB.
> GDB remains in the frame where the signal was received.
> To change this behavior use "set unwindonsignal on".
> Evaluation of the expression containing the function
> (mainshr1) will be abandoned.
> When the function is done executing, GDB will silently stop.
> (gdb) FAIL: gdb.base/shlib-call.exp: print mainshr1(1)
> step
>
> The SIGSEGV look scary until one remembers that the dummy breakpoints
> are placed on the stack, which is non-executable.  gdb translates those
> SIGSEGVs back to SIGTRAPs, provided it knows there's a breakpoint at that
> address.
>
> Looking a bit at breakpoint.c, I notice that a few ->permanent
> checks seem to have been left behind, and as result we don't actually
> remove from the target the breakpoints that were placed on top of the
> permanent breakpoints?
>
> This seems to fix the FAILs here, but I didn't run full regression
> testing.  Could you take this, test it on qemu, and and finish it off?
>
> ---
>  From 9cbd03b61441072c71d2076c1deb6766fecf25d2 Mon Sep 17 00:00:00 2001
> From: Pedro Alves <palves@redhat.com>
> Date: Mon, 6 Jul 2015 17:04:05 +0100
> Subject: [PATCH] remove left behind permanent breakpoint special casing
>
> ---
>   gdb/breakpoint.c | 11 +----------
>   1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c
> index 1481112..af0d167 100644
> --- a/gdb/breakpoint.c
> +++ b/gdb/breakpoint.c
> @@ -3892,10 +3892,6 @@ remove_breakpoint_1 (struct bp_location *bl, insertion_state_t is)
>     /* BL is never in moribund_locations by our callers.  */
>     gdb_assert (bl->owner != NULL);
>
> -  if (bl->permanent)
> -    /* Permanent breakpoints cannot be inserted or removed.  */
> -    return 0;
> -
>     /* The type of none suggests that owner is actually deleted.
>        This should not ever happen.  */
>     gdb_assert (bl->owner->type != bp_none);
> @@ -4042,10 +4038,6 @@ remove_breakpoint (struct bp_location *bl, insertion_state_t is)
>     /* BL is never in moribund_locations by our callers.  */
>     gdb_assert (bl->owner != NULL);
>
> -  if (bl->permanent)
> -    /* Permanent breakpoints cannot be inserted or removed.  */
> -    return 0;
> -
>     /* The type of none suggests that owner is actually deleted.
>        This should not ever happen.  */
>     gdb_assert (bl->owner->type != bp_none);
> @@ -4068,8 +4060,7 @@ mark_breakpoints_out (void)
>     struct bp_location *bl, **blp_tmp;
>
>     ALL_BP_LOCATIONS (bl, blp_tmp)
> -    if (bl->pspace == current_program_space
> -	&& !bl->permanent)
> +    if (bl->pspace == current_program_space)
>         bl->inserted = 0;
>   }
>
>

I've confirmed it fixes the gdbserver-specific issue here and it still 
works correctly for other setups like native GDB and simulator-based 
debugging.

I'll go ahead and push the following in, if it is ok.

Fix problems with finishing a dummy function call on simulators.

Commit Message

Comments

Patch