This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Switching architectures from a remote target


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
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]