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: "Maciej W. Rozycki" <macro at linux-mips dot org>
- Cc: Yao Qi <qiyaoltc at gmail dot com>, gdb-patches at sourceware dot org
- Date: Mon, 11 May 2015 15:08:23 +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> <alpine dot LFD dot 2 dot 11 dot 1505100137270 dot 1538 at eddie dot linux-mips dot org> <55509310 dot 6040909 at redhat dot com> <alpine dot LFD dot 2 dot 11 dot 1505111315270 dot 1538 at eddie dot linux-mips dot org>
On 05/11/2015 01:37 PM, Maciej W. Rozycki wrote:
> On Mon, 11 May 2015, Pedro Alves wrote:
>> 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.
That sounds solvable though: as that's a static property of the
target system/process, maybe gdbserver can fetch that info from elsewhere,
like somewhere under /proc, or from the auvx, or some bit set in the elf
binary (found at /proc/pid/exe). Failing that, we can have gdb tell
gdbserver early with some new packet.
Thanks,
Pedro Alves