Re: [PATCH] [gdbserver] Disable conditional breakpoints on no-hardware-single-step targets

Maciej W. Rozycki
2015-05-11T12:38:04Z

On Mon, 11 May 2015, Pedro Alves wrote:

> > A similar issue exists for the three MIPS ISA modes and gdbserver will
> > not have enough data to determine which of the two of the MIPS16 and
> > microMIPS instruction sets to use for the compressed mode. Only GDB knows
> > that, at the last resort having been told by the user.
>
> For breakpoints (z0/z1), GDB tells GDBserver the mode of instruction is
> encoded in the breakpoint's size. The tracepoint creation packets are
> older than that and only carry the address. They'll need to be
> extended to include the tracepoint's size as well. With that,
> when stepping past a gdb-set breakpoint/tracepoint, gdbserver can tell
> the mode of the instruction under the breakpoint/tracepoint from the
> breakpoint/tracepoint's size, as that's information that came from GDB.

Correct, that's not the issue.

> I assume that mode switches on MIPS are similar to ARM, with special
> branch instruction with mode encoded in in destination address? If so,
> starting from knowing the mode at PC, gdbserver should be able to
> determine the mode of all the potential next instructions on its own.

And that's where the issue is. Assuming that you're in the standard ISA
mode, you can determine that the next instruction will switch the mode to
one of the compressed ISAs, either by checking the opcode (immediate jump,
JALX) or by reading the PC to be jumped to (register jumps, JALR and JR).
What you can't determine is which of the two compressed ISAs, either
MIPS16 or microMIPS one, the instruction will switch to.

Given that the MIPS16 and the microMIPS mode cannot be implemented by a
processor both at a time you can will know which of the two is being used
once you have seen a breakpoint request for one of them. However it may
be that none has been used so far and then you have no way to know, in the
current state of affairs.

Maciej