This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Fix problems with finishing a dummy function call on simulators.
- From: Pedro Alves <palves at redhat dot com>
- To: Luis Machado <lgustavo at codesourcery dot com>, gdb-patches at sourceware dot org
- Date: Mon, 06 Jul 2015 17:15:14 +0100
- Subject: Re: [PATCH] Fix problems with finishing a dummy function call on simulators.
- Authentication-results: sourceware.org; auth=none
- References: <1433862056-18237-1-git-send-email-lgustavo at codesourcery dot com> <55772797 dot 802 at redhat dot com> <55805F52 dot 20805 at codesourcery dot com> <55816AD5 dot 6020605 at redhat dot com> <55817569 dot 7060704 at codesourcery dot com> <5581798B dot 5080207 at redhat dot com> <5581D5A9 dot 3070706 at codesourcery dot com> <559A998E dot 6010500 at redhat dot com> <559A9FCE dot 5070908 at codesourcery dot com>
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;
}
--
1.9.3