From: Luis Machado <lgustavo@codesourcery.com>
To: Pedro Alves <palves@redhat.com>, <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Fix problems with finishing a dummy function call on simulators.
Date: Mon, 06 Jul 2015 18:34:00 -0000 [thread overview]
Message-ID: <559ACA0F.7010306@codesourcery.com> (raw)
In-Reply-To: <559AA992.2020004@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 3773 bytes --]
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.
[-- Attachment #2: 0001-Fix-problems-with-finishing-a-dummy-function-call-on.patch --]
[-- Type: text/x-patch, Size: 3862 bytes --]
From c1bc516aae7a2293b4119f92432a73021865f538 Mon Sep 17 00:00:00 2001
From: Luis Machado <lgustavo@codesourcery.com>
Date: Mon, 6 Jul 2015 15:24:37 -0300
Subject: [PATCH] Fix problems with finishing a dummy function call on
simulators.
This fixes regressions introduced with the original change to not
consider permanent breakpoints always inserted:
6ae8866180bf90e9ec76c2dd34c07fd826d11a83 is the first bad commit
commit 6ae8866180bf90e9ec76c2dd34c07fd826d11a83
Author: Luis Machado <lgustavo@codesourcery.com>
Date: Wed Jun 17 16:50:57 2015 -0300
Fix problems with finishing a dummy function call on simulators.
Some checks were mistakenly left out of the original patch, which
caused the following failures:
-PASS: gdb.base/shlib-call.exp: print mainshr1(1)
-PASS: gdb.base/shlib-call.exp: step into mainshr1
+FAIL: gdb.base/shlib-call.exp: print mainshr1(1)
+FAIL: gdb.base/shlib-call.exp: step into mainshr1
-PASS: gdb.cp/chained-calls.exp: q(p())
+FAIL: gdb.cp/chained-calls.exp: q(p())
-PASS: gdb.cp/chained-calls.exp: q(p() + r())
+FAIL: gdb.cp/chained-calls.exp: q(p() + r())
-PASS: gdb.cp/chained-calls.exp: g(f(g(f() + f())) + f())
+FAIL: gdb.cp/chained-calls.exp: g(f(g(f() + f())) + f())
-PASS: gdb.cp/chained-calls.exp: *c
-PASS: gdb.cp/chained-calls.exp: *c + *c
-PASS: gdb.cp/chained-calls.exp: q(*c + *c)
+FAIL: gdb.cp/chained-calls.exp: *c
+FAIL: gdb.cp/chained-calls.exp: *c + *c
+FAIL: gdb.cp/chained-calls.exp: q(*c + *c)
-PASS: gdb.cp/classes.exp: calling method for small class
+FAIL: gdb.cp/classes.exp: calling method for small class
The above is likely caused by GDB not removing the permanent
breakpoints from the target, leading to the inferior executing
the breakpoint instruction and tripping on a SIGSEGV.
2015-07-06 Luis Machado <lgustavo@codesourcery.com>
* breakpoint.c (remove_breakpoint_1): Don't handle permanent
breakpoints in a special way.
(remove_breakpoint): Likewise.
(mark_breakpoints_out): Likewise.
---
gdb/ChangeLog | 7 +++++++
gdb/breakpoint.c | 11 +----------
2 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 4636653..5688b4a 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,10 @@
+2015-07-06 Luis Machado <lgustavo@codesourcery.com>
+
+ * breakpoint.c (remove_breakpoint_1): Don't handle permanent
+ breakpoints in a special way.
+ (remove_breakpoint): Likewise.
+ (mark_breakpoints_out): Likewise.
+
2015-07-06 Andrew Burgess <andrew.burgess@embecosm.com>
* tui/tui-data.c (tui_partial_win_by_name): Window name is const.
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.1
next prev parent reply other threads:[~2015-07-06 18:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-09 15:01 Luis Machado
2015-06-09 17:51 ` Pedro Alves
2015-06-09 18:10 ` Luis Machado
2015-06-09 18:13 ` Pedro Alves
2015-06-09 18:22 ` Luis Machado
2015-06-09 18:34 ` Luis Machado
2015-06-16 17:39 ` Luis Machado
2015-06-17 12:41 ` Pedro Alves
2015-06-17 13:26 ` Luis Machado
2015-06-17 13:43 ` Pedro Alves
2015-06-17 20:16 ` Luis Machado
2015-07-06 15:06 ` Pedro Alves
2015-07-06 15:33 ` Luis Machado
2015-07-06 16:15 ` Pedro Alves
2015-07-06 16:18 ` Luis Machado
2015-07-06 18:34 ` Luis Machado [this message]
2015-07-06 19:07 ` Pedro Alves
2015-07-06 19:11 ` Luis Machado
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=559ACA0F.7010306@codesourcery.com \
--to=lgustavo@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox