public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
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 11:31:00 -0000	[thread overview]
Message-ID: <55509310.6040909@redhat.com> (raw)
In-Reply-To: <alpine.LFD.2.11.1505100137270.1538@eddie.linux-mips.org>

On 05/10/2015 02:04 AM, Maciej W. Rozycki wrote:
> On Wed, 6 May 2015, Pedro Alves wrote:
> 
>>> It is worse if the arm/thumb interworking is considered.  Nowadays,
>>> GDBserver arm backend unconditionally inserts arm breakpoint,
>>>
>>>   /* Define an ARM-mode breakpoint; we only set breakpoints in the C
>>>      library, which is most likely to be ARM.  If the kernel supports
>>>      clone events, we will never insert a breakpoint, so even a Thumb
>>>      C library will work; so will mixing EABI/non-EABI gdbserver and
>>>      application.  */
>>> #ifndef __ARM_EABI__
>>>   (const unsigned char *) &arm_breakpoint,
>>> #else
>>>   (const unsigned char *) &arm_eabi_breakpoint,
>>> #endif
>>>
>>> note that the comments are no longer valid as C library can be compiled
>>> in thumb mode.
>>>
>>> When GDBserver steps over a breakpoint in arm mode function, which
>>> returns to thumb mode, GDBserver will insert arm mode breakpoint by
>>> mistake and the program will crash.  GDBserver alone is unable to
>>> determine the arm/thumb mode given a PC address.  See how GDB does
>>> it in arm-tdep.c:arm_pc_is_thumb.
>>
>> Of a random PC address no, but in gdbserver's case, I think that it
>> would work, because we need it to step over a breakpoint that is
>> at the current PC.  So we could:
>>
>>  #1 - Get the mode of the current PC from the thread's $cpsr register.
>>
>>  #2 - Get the mode of the next PC by looking at the instruction that is
>>       about to be executed (at current PC).  If bx and blx, which change
>>       modes, check the thumb bit of the destination address.
>>       For all other instructions, same mode as the current PC.
> 
>  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.
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.

Thanks,
Pedro Alves

  reply	other threads:[~2015-05-11 11:31 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 [this message]
2015-05-11 12:38       ` Maciej W. Rozycki
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=55509310.6040909@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=macro@linux-mips.org \
    --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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).