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 (齐尧)
next prev parent 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