This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 1/2] gdbarch software_single_step returns VEC (CORE_ADDR) *
- From: Yao Qi <qiyaoltc at gmail dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Yao Qi <qiyaoltc at gmail dot com>, gdb-patches at sourceware dot org
- Date: Fri, 29 Apr 2016 15:48:08 +0100
- Subject: Re: [PATCH 1/2] gdbarch software_single_step returns VEC (CORE_ADDR) *
- Authentication-results: sourceware.org; auth=none
- References: <1458742206-622-1-git-send-email-yao dot qi at linaro dot org> <1458742206-622-2-git-send-email-yao dot qi at linaro dot org> <56F2D1A2 dot 80103 at redhat dot com> <86egasrr2a dot fsf at gmail dot com> <b76700ae-10a5-80f8-643a-c42207095f6a at redhat dot com>
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 (éå)