This is the mail archive of the
mailing list for the GDB project.
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
On Fri, Feb 5, 2010 at 5:29 AM, Jan Kiszka <firstname.lastname@example.org> 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.
>> On Fri, Feb 5, 2010 at 03:38, Robert Barnes <email@example.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
>>> 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?
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux