Re: 64-bit Addresses in remote protocol

Joel Sherrill <[email protected]>
Newsgroups gmane.comp.gdb.devel
Message-ID <CAF9ehCXn=F5Ot+SN9_dJAbooC9FRR8ViFsqfyBw3f3-xg4EWzA@mail.gmail.com>
On Mon, Mar 22, 2021, 12:32 PM Luis Machado <[email protected]> wrote:

> Hi,
>
> On 3/22/21 1:55 PM, Joel Sherrill wrote:
> > Hi
> >
> > Over at RTEMS, we are looking at some warnings in our debug
> > server and wondering if fields described as "addr" in the gdb
> > protocol should be treated 64-bits when that target has 64-bit
> > addresses like the aarch64.
>
> 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.
>
> Does that help?
>

I think it does. Sounds right to treat it as uintptr_t when decoding it.

Unfortunately I think this means a review of our gdb server since it uses a
decode uint method a lot and each case will need to be checked to see if it
is called for an address.

Was there somewhere in the gdb documentation this was and I missed it? My
read of the protocol description focused on it as an ASCII command and not
the types they mapped to. But I admit that I might have missed something.

Thanks.

--joel


> >
> > Technically, we are looking at sweeping through our gdb server
> > and using  uintptr_t for addresses where uint32_t has been
> > ok before.
> >
> > But I wanted to make sure that our assumption that "addr" means
> > a valid target address which means it can be 32- or 64- bits based
> > on the target.
> >
> > Thanks.
> >
> > --joel
> > RTEMS
> >
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.