Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Yao Qi <qiyaoltc@gmail.com>
To: Pedro Alves <palves@redhat.com>
Cc: Yao Qi <qiyaoltc@gmail.com>,  gdb-patches@sourceware.org
Subject: Re: [PATCH 1/2] gdbarch software_single_step returns VEC (CORE_ADDR) *
Date: Fri, 29 Apr 2016 14:48:00 -0000	[thread overview]
Message-ID: <86d1p8eajb.fsf@gmail.com> (raw)
In-Reply-To: <b76700ae-10a5-80f8-643a-c42207095f6a@redhat.com> (Pedro Alves's	message of "Wed, 27 Apr 2016 16:19:14 +0100")

Pedro Alves <palves@redhat.com> writes:

> Another similar/related idea would be to go the gdbserver direction of
> storing the breakpoint's "len/kind" in the breakpoint location, as a separate
> field, instead of encoding it in the address:
>
>   /* Return the breakpoint kind for this target based on PC.  The PCPTR is
>      adjusted to the real memory location in case a flag (e.g., the Thumb bit on
>      ARM) was present in the PC.  */
>   int (*breakpoint_kind_from_pc) (CORE_ADDR *pcptr);
>
>   /* Return the software breakpoint from KIND.  KIND can have target
>      specific meaning like the Z0 kind parameter.
>      SIZE is set to the software breakpoint's length in memory.  */
>   const gdb_byte *(*sw_breakpoint_from_kind) (int kind, int *size);
>
>
> struct bp_target_info already has the "placed_size" field,
> maybe we could reuse it, just like we started from the "len"
> field on gdbserver, in 271652949894 (Support breakpoint kinds for 
> software breakpoints in GDBServer).

Yeah, I can give a try.

>
> In effect, this would move the gdbarch_remote_breakpoint_from_pc
> calls to common code, just like it happened in gdbserver.
>

gdbarch_remote_breakpoint_from_pc will be no longer needed, because
we've got "kind" field.  We can use it when sending Z packet.

> So when setting a single-step breakpoint, we'd get the "kind"
> from the current mode, and when setting breakpoints from
> user-input, we'd get it from the symbols tables / mapping symbols.

This means we need this to get the "kind" from the current mode,

  /* Return the breakpoint kind for this target based on the current
     processor state (e.g. the current instruction mode on ARM) and the
     PC.  The PCPTR is adjusted to the real memory location in case a flag
     (e.g., the Thumb bit on ARM) is present in the PC.  */
  int (*breakpoint_kind_from_current_state) (CORE_ADDR *pcptr);

and also need to pass breakpoint location to to_insert_breakpoint to get
the type of breakpoint we are inserting, right?

-- 
Yao (齐尧)


  reply	other threads:[~2016-04-29 14:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-23 14:10 [PATCH 0/2] " Yao Qi
2016-03-23 14:10 ` [PATCH 1/2] " Yao Qi
2016-03-23 17:25   ` Pedro Alves
2016-03-30 14:14     ` Yao Qi
2016-04-27 15:19       ` Pedro Alves
2016-04-29 14:48         ` Yao Qi [this message]
2016-05-02 10:21           ` Pedro Alves
2016-03-23 14:10 ` [PATCH 2/2] Remove gdbarch method displaced_step_hw_singlestep Yao Qi
2016-03-23 17:26   ` Pedro Alves
2016-05-09 11:05     ` 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=86d1p8eajb.fsf@gmail.com \
    --to=qiyaoltc@gmail.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.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