public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug gdb/28947] GDB does not remove AArch64 pointer signatures before doing memory accesses
Date: Fri, 16 Dec 2022 11:19:56 +0000	[thread overview]
Message-ID: <bug-28947-4717-hSmbRLLVdI@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-28947-4717@http.sourceware.org/bugzilla/>

https://sourceware.org/bugzilla/show_bug.cgi?id=28947

--- Comment #7 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Luis Machado <luisgpm@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=d88cb738e6a7a7179dfaff8af78d69250c852af1

commit d88cb738e6a7a7179dfaff8af78d69250c852af1
Author: Luis Machado <luis.machado@arm.com>
Date:   Tue May 24 23:31:09 2022 +0100

    [aarch64] Fix removal of non-address bits for PAuth

    PR gdb/28947

    The address_significant gdbarch setting was introduced as a way to remove
    non-address bits from pointers, and it is specified by a constant.  This
    constant represents the number of address bits in a pointer.

    Right now AArch64 is the only architecture that uses it, and 56 was a
    correct option so far.

    But if we are using Pointer Authentication (PAuth), we might use up to 2
bytes
    from the address space to store the required information.  We could also
have
    cases where we're using both PAuth and MTE.

    We could adjust the constant to 48 to cover those cases, but this doesn't
    cover the case where GDB needs to sign-extend kernel addresses after
removal
    of the non-address bits.

    This has worked so far because bit 55 is used to select between
kernel-space
    and user-space addresses.  But trying to clear a range of bits crossing the
    bit 55 boundary requires the hook to be smarter.

    The following patch renames the gdbarch hook from significant_addr_bit to
    remove_non_address_bits and passes a pointer as opposed to the number of
    bits.  The hook is now responsible for removing the required non-address
bits
    and sign-extending the address if needed.

    While at it, make GDB and GDBServer share some more code for aarch64 and
add a
    new arch-specific testcase gdb.arch/aarch64-non-address-bits.exp.

    Bug-url: https://sourceware.org/bugzilla/show_bug.cgi?id=28947

    Approved-By: Simon Marchi <simon.marchi@efficios.com>

-- 
You are receiving this mail because:
You are on the CC list for the bug.

  parent reply	other threads:[~2022-12-16 11:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-07 11:32 [Bug gdb/28947] New: " david.spickett at linaro dot org
2022-03-07 11:45 ` [Bug gdb/28947] " luis.machado at arm dot com
2022-03-07 11:46 ` luis.machado at arm dot com
2022-03-07 13:28 ` luis.machado at arm dot com
2022-05-24  8:04 ` luis.machado at arm dot com
2022-05-24  8:06 ` luis.machado at arm dot com
2022-05-24  9:06 ` david.spickett at linaro dot org
2022-05-26  8:23 ` luis.machado at arm dot com
2022-09-15  7:58 ` luis.machado at arm dot com
2022-12-16 11:19 ` cvs-commit at gcc dot gnu.org [this message]
2022-12-16 11:22 ` luis.machado at arm dot com

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=bug-28947-4717-hSmbRLLVdI@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=gdb-prs@sourceware.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).