This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] [gdbserver] Disable conditional breakpoints on no-hardware-single-step targets
- From: Pedro Alves <palves at redhat dot com>
- To: Antoine Tremblay <antoine dot tremblay at ericsson dot com>, Yao Qi <qiyaoltc at gmail dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 08 May 2015 13:29:25 +0100
- Subject: Re: [PATCH] [gdbserver] Disable conditional breakpoints on no-hardware-single-step targets
- Authentication-results: sourceware.org; auth=none
- References: <1430411029-12097-1-git-send-email-qiyaoltc at gmail dot com> <554A368F dot 4060309 at redhat dot com> <86oalwvf38 dot fsf at gmail dot com> <554B5052 dot 2090904 at ericsson dot com> <554CA308 dot 1030509 at redhat dot com> <554CA83F dot 7080909 at ericsson dot com>
On 05/08/2015 01:12 PM, Antoine Tremblay wrote:
> This looks very nice thanks! , but I do have one question , why is the
> result a VEC ?
>
> From the context and current code won't we have only one next instruction ?
Nope. Most frequent case is conditional branches where we don't know
where the program will end up. Might be the destination of the branch,
if the instruction evals true, or after the branch, if the condition evals false.
Even though the arm code manages to evaluate most conditions itself upfront,
there are still some cases where it can't. The way we handle it currently
is that the get_next_pc functions call insert extra single-step breakpoints
themselves, like e.g., in thumb_get_next_pc_raw:
else
{
int cond_negated;
/* There are conditional instructions after this one.
If this instruction modifies the flags, then we can
not predict what the next executed instruction will
be. Fortunately, this instruction is architecturally
forbidden to branch; we know it will fall through.
Start by skipping past it. */
pc += thumb_insn_size (inst1);
itstate = thumb_advance_itstate (itstate);
/* Set a breakpoint on the following instruction. */
gdb_assert ((itstate & 0x0f) != 0);
arm_insert_single_step_breakpoint (gdbarch, aspace,
MAKE_THUMB_ADDR (pc));
cond_negated = (itstate >> 4) & 1;
So you see how this is a misleading/surprising interface, naturally
something that grew organically instead of being designed for
multiple potential destinations.
Another case where the ARM code (and others like PPC) need more than
one "next pc" is when dealing with atomic sequences. See e.g.,
arm_deal_with_atomic_sequence_raw. gdbserver needs all that
atomic sequence code too.
>
> Also, if you may,file structure wise, where would be a good place for
> this abstration layer in your view ?
Good question. Maybe a new gdb/arch/ directory. But I'd be fine
with putting it in gdb/common/ for now.
Thanks,
Pedro Alves