From: Robert Barnes <robcb85@gmail.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Hui Zhu <teawater@gmail.com>, gdb@sourceware.org
Subject: Re: Switching architectures from a remote target
Date: Tue, 09 Feb 2010 18:40:00 -0000 [thread overview]
Message-ID: <23c0f921002091039g3e3bd68cw7e4792f6e511f431@mail.gmail.com> (raw)
In-Reply-To: <4B6C0F15.4030006@siemens.com>
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
>
prev parent reply other threads:[~2010-02-09 18:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-04 19:38 Robert Barnes
2010-02-05 6:50 ` Hui Zhu
2010-02-05 12:29 ` Jan Kiszka
2010-02-09 18:40 ` Robert Barnes [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=23c0f921002091039g3e3bd68cw7e4792f6e511f431@mail.gmail.com \
--to=robcb85@gmail.com \
--cc=gdb@sourceware.org \
--cc=jan.kiszka@siemens.com \
--cc=teawater@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox