[PATCH v3 1/3] rtems-debugger: Fixed 32bit pointers

[Joel Sherrill]

On Mon, Mar 22, 2021, 3:54 PM Chris Johns <chrisj at rtems.org> wrote:

> On 23/3/21 4:58 am, Joel Sherrill wrote:
> > On Mon, Mar 22, 2021 at 12:54 PM Joel Sherrill <joel at rtems.org
> > <mailto:joel at rtems.org>> wrote:
> >
> >     I posted to the gdb mailing list and this is the response:
> >
> >     "If the inferior is using 64-bit addresses, then the remote protocol
> will
> >     also use 64-bit addresses. If we have a 32-bit inferior running on
> >     aarch64 hardware, we'll have 32-bit addresses over the remote
> protocol
> >     as well.
> >
> >     Even when we're using 64-bit addresses, the remote protocol may not
> pad
> >     it with zeroes to make it 64-bit, but it should still be handled as
> 64-bit."
> >
> >     Unfortunately, I think this means that everywhere the debugger code
> >     uses a decode (is there an encode?) uint to decode an address that
> >     code needs to change to decode an address (e.g. uintptr) where one
> is
> >     expected in the protocol. And all target addresses in the debugger
> need
> >     to change to uintptr_t.
> >
> > Luis from gdb just followed up and suggested we always treat it as
> > 64-bit and cast to 32-bits. I think uintptr_t is the right answer but I
> > wanted to pass that along.
>
> Thanks and yes this makes sense. Great idea to ask over at gdb.
>

I've chatted with Steven privately to explain this. He's going to add a
decode address function and then pull the thread from there. I think that
will probably be enough to get this right combined with testing on the BBB.

>
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210322/6fc670a7/attachment.html>