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.