This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[PATCH 3/8] Break at each iteration for breakpoints placed on a while statement
- From: Kevin Buettner <kevinb at redhat dot com>
- To: gdb-patches at sourceware dot org
- Date: Wed, 19 Aug 2015 00:03:34 -0700
- Subject: [PATCH 3/8] Break at each iteration for breakpoints placed on a while statement
- Authentication-results: sourceware.org; auth=none
- References: <20150818235334 dot 1afb0c85 at pinnacle dot lan>
This patch changes create_sals_line_offset() in linespec.c so that, for
a given SAL, if that SAL's address (pc) refers to an unconditional
branch instruction whose branch target also refers to the same SAL, then
the branch target is used for the SAL instead.
The pratical effect of this is that a breakpoint placed on a while
loop will break at the evaluation of the condition instead of at the
unconditional branch which transfers control to the starting address
for the evaluation of the condition.
Consider the following code snippet (which is taken from one of the
new tests for this patch set):
9 while (v < 3) /* Loop 1 condition */
10 {
11 v++; /* Loop 1 increment */
12 }
This is compiled as the following x86_64 code:
0x000000000040059e <loop_test+14>: jmp 0x4005af <loop_test+31>
0x00000000004005a0 <loop_test+16>: mov 0x200a8a(%rip),%eax # 0x601030 <v>
0x00000000004005a6 <loop_test+22>: add $0x1,%eax
0x00000000004005a9 <loop_test+25>: mov %eax,0x200a81(%rip) # 0x601030 <v>
0x00000000004005af <loop_test+31>: mov 0x200a7b(%rip),%eax # 0x601030 <v>
0x00000000004005b5 <loop_test+37>: cmp $0x2,%eax
0x00000000004005b8 <loop_test+40>: jle 0x4005a0 <loop_test+16>
If a breakpoint is placed on line 9, which begins at loop_test+14, this
change/patch causes the breakpoint to be placed on loop_test+31, which is
the starting address for the evaluation of the condition.
In order for this to work, an architecture specific method,
unconditional_branch_address, was introduced in an earlier patch in
the set. I've implemented this method for x86_64, i386, arm, thumb,
powerpc, rx, and rl78.
I've tested on each of these architectures and see no regressions.
gdb/ChangeLog:
* linespec.c (addr_in_sals): New function.
(create_sals_line_offset): Adjust SAL whose pc refers to an
unconditional branch whose target is the same line.
---
gdb/linespec.c | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/gdb/linespec.c b/gdb/linespec.c
index 00fa4ba..2e0146d 100644
--- a/gdb/linespec.c
+++ b/gdb/linespec.c
@@ -1808,6 +1808,29 @@ canonicalize_linespec (struct linespec_state *state, const linespec_p ls)
}
}
+/* Return 1 if one of the SALS between 0 and NELTS contains ADDR.
+ Return 0 otherwise. */
+
+static int
+addr_in_sals (CORE_ADDR addr, int nelts, struct symtab_and_line *sals)
+{
+ int i;
+
+ for (i = 0; i < nelts; i++)
+ {
+ struct symtab_and_line sal;
+
+ if (sals[i].end == 0)
+ sal = find_pc_sect_line (sals[i].pc, sals[i].section, 0);
+ else
+ sal = sals[i];
+
+ if (sal.pc <= addr && addr < sal.end)
+ return 1;
+ }
+ return 0;
+}
+
/* Given a line offset in LS, construct the relevant SALs. */
static struct symtabs_and_lines
@@ -1933,6 +1956,18 @@ create_sals_line_offset (struct linespec_state *self,
struct symbol *sym = (blocks[i]
? block_containing_function (blocks[i])
: NULL);
+ CORE_ADDR branch_addr = gdbarch_unconditional_branch_address
+ (get_current_arch (), intermediate_results.sals[i].pc);
+
+ /* Only use branch if it's in the same block and is also
+ within one of the sals from the initial list. */
+ if (branch_addr != 0 && blocks[i]->startaddr <= branch_addr
+ && branch_addr < blocks[i]->endaddr
+ && addr_in_sals (branch_addr, intermediate_results.nelts,
+ intermediate_results.sals))
+ {
+ intermediate_results.sals[i].pc = branch_addr;
+ }
if (self->funfirstline)
skip_prologue_sal (&intermediate_results.sals[i]);