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

["Maciej W. Rozycki" <macro at linux-mips dot org>]

On Mon, 11 May 2015, Pedro Alves wrote:

> >  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.

 Good point, thanks for the hint!  Gdbserver itself can indeed peek at the 
executable, and binaries that contain microMIPS code will have that noted 
in the ELF header, in `e_flags'.  Conversely, the lack of such annotation 
implies the MIPS16 mode -- if ever requested, that is, as the lack of 
microMIPS annotation does not mean any MIPS16 code is actually present, it 
may in fact be a plain MIPS binary.

 So there's still the corner case of a MIPS16 binary accidentally run on 
microMIPS hardware, as that cannot be detected until a switch to the 
compressed mode has been made.  In which case the debuggee will likely 
crash anyway, so it might not be an interesting case to handle; otherwise 
perhaps the presence of support for the MIPS16 or microMIPS instruction 
set is something worth exporting via AT_HWCAP.  I don't know offhand how 
the two microMIPS software breakpoint instruction encodings used by GDB 
decode in the MIPS16 instruction set.

 Another issue is AFAIK the Linux kernel does not check the microMIPS flag 
in `e_flags' either and will happily attempt to run such a binary on 
MIPS16 or plain MIPS hardware.  But if anything, that's a kernel bug.

  Maciej