Switching architectures from a remote target

Switching architectures from a remote target

[Robert Barnes]

I am using GDB to interface with a remote target over serial. The
target architecture changes during execution (e.g. 32-bit to 64-bit).
When the architecture changes I need gdb to change its internal
representation of the remote architecture at the same time. The
primary problem is the remote 'g' command, it's return packet size is
determined by the initial call. When the architecture changes, the
size and number of registers may change, thus the size of the 'g'
packet changes. Yet gdb is still expecting the old size.

This problem is addressed in section 7 of "Multi-arching Insights and
GDB" by Andrew Cagney
(http://www.gnu.org/software/gdb/papers/multi-arch/real-multi-arch/).
As far as I can tell the recommendations haven't been implemented.

Are there any workarounds or solutions to the general problem of
handling changing architectures on a remote target?

Thanks!

-Rob

Re: Switching architectures from a remote target

[Hui Zhu]

Try "set architecture"
But I don't have a inferior that can change bit when it's debug. I
don't sure if it works or not.

Thanks,
Hui


On Fri, Feb 5, 2010 at 03:38, Robert Barnes <robcb85@gmail.com> wrote:
> I am using GDB to interface with a remote target over serial. The
> target architecture changes during execution (e.g. 32-bit to 64-bit).
> When the architecture changes I need gdb to change its internal
> representation of the remote architecture at the same time. The
> primary problem is the remote 'g' command, it's return packet size is
> determined by the initial call. When the architecture changes, the
> size and number of registers may change, thus the size of the 'g'
> packet changes. Yet gdb is still expecting the old size.
>
> This problem is addressed in section 7 of "Multi-arching Insights and
> GDB" by Andrew Cagney
> (http://www.gnu.org/software/gdb/papers/multi-arch/real-multi-arch/).
> As far as I can tell the recommendations haven't been implemented.
>
> Are there any workarounds or solutions to the general problem of
> handling changing architectures on a remote target?
>
> Thanks!
>
> -Rob
>

Re: Switching architectures from a remote target

[Jan Kiszka]

Hui Zhu wrote:
> Try "set architecture"
> But I don't have a inferior that can change bit when it's debug. I
> don't sure if it works or not.

qemu's gdbstub is an example for such a scenario. It currently switches
the arch dynamically when the guest moves from 32 to 64 bit mode and
vice versa. Not nice, but the best we can do until someone (us included)
finds the time to fix x86 gdb.

Jan

> 
> On Fri, Feb 5, 2010 at 03:38, Robert Barnes <robcb85@gmail.com> wrote:
>> I am using GDB to interface with a remote target over serial. The
>> target architecture changes during execution (e.g. 32-bit to 64-bit).
>> When the architecture changes I need gdb to change its internal
>> representation of the remote architecture at the same time. The
>> primary problem is the remote 'g' command, it's return packet size is
>> determined by the initial call. When the architecture changes, the
>> size and number of registers may change, thus the size of the 'g'
>> packet changes. Yet gdb is still expecting the old size.
>>
>> This problem is addressed in section 7 of "Multi-arching Insights and
>> GDB" by Andrew Cagney
>> (http://www.gnu.org/software/gdb/papers/multi-arch/real-multi-arch/).
>> As far as I can tell the recommendations haven't been implemented.
>>
>> Are there any workarounds or solutions to the general problem of
>> handling changing architectures on a remote target?
>>
>> Thanks!
>>
>> -Rob
>>
> 

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: Switching architectures from a remote target

[Robert Barnes]

Thanks for the reply.

I downloaded and tested qemu over gdb. qemu's gdb stub does
dynamically switch to 64-bit from 32-bit, but gdb is not aware of
this. The initial response after the switch is "'g' packet to long".
Doing "set architecture i386:x86_64" fixes this. However, if a user
starts gdb in 64-bit and pauses the guest while it is 32-bit, qemu
still sends g packets in 32-bit. The result is all the registers are
wrong, with no errors reported. If the guest architecture then
switches to 64-bit, you will get a "'g' packet to long" error even
though the gdb architecture is already set to i386:x86_64, and you
can't get this to go away. This is a fundamental problem in the gdb
remote protocol and I don't think it can be solved inside the gdb
stub.


On Fri, Feb 5, 2010 at 5:29 AM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> Hui Zhu wrote:
>> Try "set architecture"
>> But I don't have a inferior that can change bit when it's debug. I
>> don't sure if it works or not.
>
> qemu's gdbstub is an example for such a scenario. It currently switches
> the arch dynamically when the guest moves from 32 to 64 bit mode and
> vice versa. Not nice, but the best we can do until someone (us included)
> finds the time to fix x86 gdb.
>
> Jan
>
>>
>> On Fri, Feb 5, 2010 at 03:38, Robert Barnes <robcb85@gmail.com> wrote:
>>> I am using GDB to interface with a remote target over serial. The
>>> target architecture changes during execution (e.g. 32-bit to 64-bit).
>>> When the architecture changes I need gdb to change its internal
>>> representation of the remote architecture at the same time. The
>>> primary problem is the remote 'g' command, it's return packet size is
>>> determined by the initial call. When the architecture changes, the
>>> size and number of registers may change, thus the size of the 'g'
>>> packet changes. Yet gdb is still expecting the old size.
>>>
>>> This problem is addressed in section 7 of "Multi-arching Insights and
>>> GDB" by Andrew Cagney
>>> (http://www.gnu.org/software/gdb/papers/multi-arch/real-multi-arch/).
>>> As far as I can tell the recommendations haven't been implemented.
>>>
>>> Are there any workarounds or solutions to the general problem of
>>> handling changing architectures on a remote target?
>>>
>>> Thanks!
>>>
>>> -Rob
>>>
>>
>
> --
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux
>