From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Pedro Alves <palves@redhat.com>
Cc: Yao Qi <qiyaoltc@gmail.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH] [gdbserver] Disable conditional breakpoints on no-hardware-single-step targets
Date: Mon, 11 May 2015 12:38:00 -0000 [thread overview]
Message-ID: <alpine.LFD.2.11.1505111315270.1538@eddie.linux-mips.org> (raw)
In-Reply-To: <55509310.6040909@redhat.com>
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
next prev parent reply other threads:[~2015-05-11 12:38 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1430411029-12097-1-git-send-email-qiyaoltc@gmail.com>
2015-05-06 15:43 ` Pedro Alves
2015-05-07 10:48 ` Yao Qi
2015-05-07 11:45 ` Antoine Tremblay
2015-05-08 11:50 ` Pedro Alves
2015-05-08 12:12 ` Antoine Tremblay
2015-05-08 12:29 ` Pedro Alves
2015-05-08 12:35 ` Antoine Tremblay
2015-05-08 11:02 ` Pedro Alves
2015-05-10 1:04 ` Maciej W. Rozycki
2015-05-11 11:31 ` Pedro Alves
2015-05-11 12:38 ` Maciej W. Rozycki [this message]
2015-05-11 14:08 ` Pedro Alves
2015-05-11 17:40 ` Maciej W. Rozycki
[not found] ` <55426205.3070901@ericsson.com>
2015-05-01 14:18 ` Yao Qi
2015-05-08 12:18 ` Luis Machado
2015-05-08 13:14 ` Yao Qi
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=alpine.LFD.2.11.1505111315270.1538@eddie.linux-mips.org \
--to=macro@linux-mips.org \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
--cc=qiyaoltc@gmail.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