Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Thompson <daniel.thompson@linaro.org>
To: Pedro Alves <palves@redhat.com>
Cc: Omair Javaid <omair.javaid@linaro.org>,
	Yao Qi <qiyaoltc@gmail.com>,
	GDB Patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH 0/3 v3] [AArch64] Support tagged pointer
Date: Tue, 24 Apr 2018 15:44:00 -0000	[thread overview]
Message-ID: <20180424154444.iotyh67w4sb7lu7j@holly.lan> (raw)
In-Reply-To: <45f45c80-1d25-dae7-1659-2545c0eaae51@redhat.com>

On Tue, Apr 24, 2018 at 12:39:15PM +0100, Pedro Alves wrote:
> On 04/23/2018 08:50 AM, Omair Javaid wrote:
> > On 20 April 2018 at 21:13, Daniel Thompson <daniel.thompson@linaro.org> wrote:
> 
> >> Perhaps a dumb question but could gdb be persuaded to mask the pointers at a lower level.
> >>
> >> The current patches end up masking the pointer tags relatively early, which results in masked pointers being sent via the gdb remote protocol (which is what causes some of the problems at present: kgdb and OpenOCD get asked for the wrong pointer).
> >>
> >> If the pointers were masked as the arguments to ptrace() were marshaled this would behave much more like the real hardware and would make debugging Linux kernel mode entirely transparent (since you cannot ptrace() kernel memory we would never try masking out the tag).
> > 
> > Although this can be done with a hook but will require some
> > fundamental changes to the way ptrace inf_ptrace_xfer_partial memory
> > accesses routines are written. Currently we use a generic
> > implementation inf_ptrace_xfer_partial for all target architectures.
> > Same is the case with GDBServer it just handles the ptrace calls
> > except in a few cases where we need extra architecture specific code
> > before ptrace call like setting hardware breakpoints watchpoints etc.
> > 
> > As top byte in tagged address is essentially data, pushing masking
> > down to gdbserver will mean that we ll be sending out data mangled as
> > part of the address. Passing mangled address over RSP expecting other
> > side will correct it doesnt sound right.
> > 
> > Lets see what Pedro has to see on this.
> 
> It seems like you are proposing going back to what was originally
> proposed in v1.  I think these urls link through all of the
> history:
> 
>  v1:
>  https://sourceware.org/ml/gdb-patches/2017-10/msg00593.html
>  v2:
>  https://sourceware.org/ml/gdb-patches/2017-10/msg00792.html
>  v3:
>  https://sourceware.org/ml/gdb-patches/2017-12/msg00159.html
> 
> As can be seen in v2, as soon we started considering watchpoints,
> here:
>   https://sourceware.org/ml/gdb-patches/2017-10/msg00793.html
> the gdb core needed to be made aware of tagged pointers, the bit
> masking could no longer be deferred to the lower level ptrace calls
> alone.  And then given that the core of gdb needs to know to
> mask out tagged address, by v3, we had no masking at the ptrace
> level anymore.  So I'm not sure how that would work; we'd need
> a more detailed proposal.

Thanks for the links.

If you've been round this loop once before I don't think I want to
encourage anyone to go round it again.


Daniel.


  reply	other threads:[~2018-04-24 15:44 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-08 10:04 Yao Qi
2017-12-08 10:04 ` [PATCH 3/3] Clear non-significant bits of address in watchpoint Yao Qi
2017-12-08 12:23   ` Pedro Alves
2017-12-08 10:04 ` [PATCH 2/3] Adjust breakpoint address by clearing non-significant bits Yao Qi
2017-12-08 12:22   ` Pedro Alves
2017-12-08 10:04 ` [PATCH 1/3] Clear non-significant bits of address on memory access Yao Qi
2017-12-08 12:22   ` Pedro Alves
2017-12-08 15:13     ` Ulrich Weigand
2017-12-08 15:36       ` Yao Qi
2017-12-19 13:50   ` Ulrich Weigand
2017-12-19 15:41     ` Yao Qi
2017-12-19 16:15       ` Ulrich Weigand
2017-12-20  9:57         ` Yao Qi
2017-12-20 13:03           ` [pushed] Fix Cell/B.E. regression (Re: [PATCH 1/3] Clear non-significant bits of address on memory access) Ulrich Weigand
2017-12-20 13:59             ` Yao Qi
2017-12-08 12:24 ` [PATCH 0/3 v3] [AArch64] Support tagged pointer Pedro Alves
2017-12-08 17:31 ` Yao Qi
2018-04-11  0:16   ` Omair Javaid
2018-04-11  0:37     ` Omair Javaid
2018-04-11  2:46       ` Simon Marchi
2018-04-11 10:14     ` Pedro Alves
2018-04-11 11:13       ` Omair Javaid
2018-04-11 11:19         ` Pedro Alves
2018-04-11 12:01           ` Omair Javaid
2018-04-11 18:27             ` Pedro Alves
2018-04-16  1:36               ` Omair Javaid
2018-04-16 22:57                 ` Pedro Alves
2018-04-20 14:34                   ` Omair Javaid
2018-04-20 16:13                     ` Daniel Thompson
2018-04-23  7:50                       ` Omair Javaid
2018-04-24 11:39                         ` Pedro Alves
2018-04-24 15:44                           ` Daniel Thompson [this message]
2018-04-24 11:48                     ` Pedro Alves
2018-04-24 16:05                       ` Daniel Thompson
2018-04-24 23:42                         ` Omair Javaid
2018-04-25  0:09                           ` Andrew Pinski
2018-04-25  8:04                           ` Daniel Thompson
2018-04-26  8:11                             ` Omair Javaid
2018-04-27 16:29                               ` Daniel Thompson
2018-04-30 13:42                                 ` Omair Javaid

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=20180424154444.iotyh67w4sb7lu7j@holly.lan \
    --to=daniel.thompson@linaro.org \
    --cc=gdb-patches@sourceware.org \
    --cc=omair.javaid@linaro.org \
    --cc=palves@redhat.com \
    --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