This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 0/3 v3] [AArch64] Support tagged pointer


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]