This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCHv5] aarch64: detect atomic sequences like other ll/sc architectures
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Kyle McMartin <kmcmarti at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Wed, 7 May 2014 06:52:17 -0700
- Subject: Re: [PATCHv5] aarch64: detect atomic sequences like other ll/sc architectures
- Authentication-results: sourceware.org; auth=none
- References: <20140424183510 dot GI7588 at redacted dot bos dot redhat dot com> <20140430160450 dot GE2148 at redacted dot bos dot redhat dot com>
Hi Kyle,
> 2014-04-30 Kyle McMartin <kyle@redhat.com>
>
> gdb:
> * aarch64-tdep.c (aarch64_software_single_step): New function.
> (aarch64_gdbarch_init): Handle single stepping of atomic sequences
> with aarch64_software_single_step.
>
> gdb/testsuite:
> * gdb.arch/aarch64-atomic-inst.c: New file.
> * gdb.arch/aarch64-atomic-inst.exp: New file.
Sorry for the delay. One question, see below.
> gdb/aarch64-tdep.c | 79 ++++++++++++++++++++++++++
> gdb/testsuite/gdb.arch/aarch64-atomic-inst.c | 48 ++++++++++++++++
> gdb/testsuite/gdb.arch/aarch64-atomic-inst.exp | 48 ++++++++++++++++
> 3 files changed, 175 insertions(+)
> create mode 100644 gdb/testsuite/gdb.arch/aarch64-atomic-inst.c
> create mode 100644 gdb/testsuite/gdb.arch/aarch64-atomic-inst.exp
>
> diff --git a/gdb/aarch64-tdep.c b/gdb/aarch64-tdep.c
> index bba10d8..4abe36e 100644
> --- a/gdb/aarch64-tdep.c
> +++ b/gdb/aarch64-tdep.c
> @@ -2509,6 +2509,84 @@ value_of_aarch64_user_reg (struct frame_info *frame, const void *baton)
> }
>
>
> +/* Implement the "software_single_step" gdbarch method, needed to
> + single step through atomic sequences on AArch64. */
> +
> +static int
> +aarch64_software_single_step (struct frame_info *frame)
> +{
> + struct gdbarch *gdbarch = get_frame_arch (frame);
> + struct address_space *aspace = get_frame_address_space (frame);
> + enum bfd_endian byte_order_for_code = gdbarch_byte_order_for_code (gdbarch);
AndrewP said that the code is always LE, so why not just use
BFD_ENDIAN_LITTLE in this case, rather than go through
byte_order_for_code?
--
Joel