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 > > >