* 64-bit Addresses in remote protocol
@ 2021-03-22 16:55 Joel Sherrill
2021-03-22 17:32 ` Luis Machado
0 siblings, 1 reply; 4+ messages in thread
From: Joel Sherrill @ 2021-03-22 16:55 UTC (permalink / raw)
To: gdb
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.
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: 64-bit Addresses in remote protocol
2021-03-22 16:55 64-bit Addresses in remote protocol Joel Sherrill
@ 2021-03-22 17:32 ` Luis Machado
2021-03-22 17:38 ` Joel Sherrill
0 siblings, 1 reply; 4+ messages in thread
From: Luis Machado @ 2021-03-22 17:32 UTC (permalink / raw)
To: joel, gdb
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?
>
> 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
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: 64-bit Addresses in remote protocol
2021-03-22 17:32 ` Luis Machado
@ 2021-03-22 17:38 ` Joel Sherrill
2021-03-22 17:52 ` Luis Machado
0 siblings, 1 reply; 4+ messages in thread
From: Joel Sherrill @ 2021-03-22 17:38 UTC (permalink / raw)
To: Luis Machado; +Cc: gdb
On Mon, Mar 22, 2021, 12:32 PM Luis Machado <luis.machado@linaro.org> 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
> >
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: 64-bit Addresses in remote protocol
2021-03-22 17:38 ` Joel Sherrill
@ 2021-03-22 17:52 ` Luis Machado
0 siblings, 0 replies; 4+ messages in thread
From: Luis Machado @ 2021-03-22 17:52 UTC (permalink / raw)
To: joel; +Cc: gdb
On 3/22/21 2:38 PM, Joel Sherrill wrote:
>
>
> On Mon, Mar 22, 2021, 12:32 PM Luis Machado <luis.machado@linaro.org
> <mailto:luis.machado@linaro.org>> 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.
Can you switch to decoding 64-bit values by default and casting to
32-bit when necessary?
>
> 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.
I don't think so. This is all more or less implicit and there doesn't
seem to be any formal documentation about what "addr" in the remote
protocol should look like.
For example, there are packets that refer to "addr" as an address and
nothing more.
Some others, like 't', tell us something more: "There must be at least 3
digits in addr".
So, unfortunately, there isn't a standard way addr should be formatted.
But most of the uses match the inferior's address size.
>
> 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
> >
>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-03-22 17:52 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-22 16:55 64-bit Addresses in remote protocol Joel Sherrill
2021-03-22 17:32 ` Luis Machado
2021-03-22 17:38 ` Joel Sherrill
2021-03-22 17:52 ` Luis Machado
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).