From: Pedro Alves <palves@redhat.com>
To: Yao Qi <qiyaoltc@gmail.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH 3/3] [AArch64] Remove tag from address for watchpoint
Date: Thu, 09 Nov 2017 20:30:00 -0000 [thread overview]
Message-ID: <2fe62186-f1db-cf5c-f0e2-c18e35089dd9@redhat.com> (raw)
In-Reply-To: <1509006590-9401-4-git-send-email-yao.qi@linaro.org>
On 10/26/2017 09:29 AM, Yao Qi wrote:
> +typedef CORE_ADDR (gdbarch_addr_tag_remove_ftype) (struct gdbarch *gdbarch, CORE_ADDR addr);
> +extern CORE_ADDR gdbarch_addr_tag_remove (struct gdbarch *gdbarch, CORE_ADDR addr);
> +extern void set_gdbarch_addr_tag_remove (struct gdbarch *gdbarch, gdbarch_addr_tag_remove_ftype *addr_tag_remove);
> +
> /* FIXME/cagney/2001-01-18: This should be split in two. A target method that
> indicates if the target needs software single step. An ISA method to
> implement it.
> diff --git a/gdb/gdbarch.sh b/gdb/gdbarch.sh
> index 6459b12..1f673e7 100755
> --- a/gdb/gdbarch.sh
> +++ b/gdb/gdbarch.sh
> @@ -621,6 +621,11 @@ m;CORE_ADDR;convert_from_func_ptr_addr;CORE_ADDR addr, struct target_ops *targ;a
> # possible it should be in TARGET_READ_PC instead).
> m;CORE_ADDR;addr_bits_remove;CORE_ADDR addr;addr;;core_addr_identity;;0
>
> +# On some machines, there are bits in address which are ignored by the
> +# kernel, the hardeware, etc. They are called "tag", which can be
> +# regarded as additional data associated with the address.
> +m;CORE_ADDR;addr_tag_remove;CORE_ADDR addr;addr;;core_addr_identity;;0
typo: "hardeware".
Hmmm. We have gdbarch_addr_bit / addr_bit to represent the size
of a target address. I'm thinking that instead of addr_tag_remove,
this would a bit more in line with the current scheme if this were
a new "significant_addr_bit" gdbarch property? I.e.:
/* On some machines, not all bits of an address word are significant.
For example, on Aarch64, the top bits of an address known as the "tag"
are ignored by the kernel, the hardware, etc. and can be regarded as
additional data associated with the address. */
int gdbarch_significant_addr_bit (struct gdbarch *gdbarch);
significant_addr_bit would default to addr_bit.
And then at places where we need to save or compare memory addresses,
like in the watchpoint location addresses case we strip out / ignore
non-significant bits.
And the next question is: if you're adding a gdbarch hook such as
this one (either significant_addr_bit or addr_tag_remove)
why not use it for all the cases handled by the different patches in
this series, instead of using different solutions for each case?
I.e., for memory access, saving breakpoint and watchpoint
location addresses, the dcache, and any other future case we run
into, like e.g., maybe agent expressions.
Thanks,
Pedro Alves
next prev parent reply other threads:[~2017-11-09 20:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-26 8:29 [PATCH 0/3 v2] [AArch64] Support tagged pointer Yao Qi
2017-10-26 8:30 ` [PATCH 2/3] [AArch64] Adjust breakpoint on tagged address Yao Qi
2017-10-26 8:30 ` [PATCH 3/3] [AArch64] Remove tag from address for watchpoint Yao Qi
2017-11-09 20:30 ` Pedro Alves [this message]
2017-11-09 21:08 ` Simon Marchi
2017-11-09 21:20 ` Yao Qi
2017-11-09 21:09 ` Yao Qi
2017-11-09 22:25 ` Pedro Alves
2017-10-26 8:30 ` [PATCH 1/3] [AArch64 Linux] Get rid of top byte from tagged address on memory access Yao Qi
2017-11-09 20:24 ` Pedro Alves
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=2fe62186-f1db-cf5c-f0e2-c18e35089dd9@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.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