On Mon, Mar 22, 2021, 3:54 PM Chris Johns <chr...@rtems.org> wrote: > On 23/3/21 4:58 am, Joel Sherrill wrote: > > On Mon, Mar 22, 2021 at 12:54 PM Joel Sherrill <j...@rtems.org > > <mailto:j...@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 >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
