From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13593 invoked by alias); 9 Feb 2010 18:40:07 -0000 Received: (qmail 13580 invoked by uid 22791); 9 Feb 2010 18:40:06 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from ey-out-1920.google.com (HELO ey-out-1920.google.com) (74.125.78.147) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 09 Feb 2010 18:40:02 +0000 Received: by ey-out-1920.google.com with SMTP id 26so1601584eyw.42 for ; Tue, 09 Feb 2010 10:39:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.86.213 with SMTP id w63mr2210832wee.71.1265740799708; Tue, 09 Feb 2010 10:39:59 -0800 (PST) In-Reply-To: <4B6C0F15.4030006@siemens.com> References: <23c0f921002041138k1d989b9cs8423911108499331@mail.gmail.com> <4B6C0F15.4030006@siemens.com> Date: Tue, 09 Feb 2010 18:40:00 -0000 Message-ID: <23c0f921002091039g3e3bd68cw7e4792f6e511f431@mail.gmail.com> Subject: Re: Switching architectures from a remote target From: Robert Barnes To: Jan Kiszka Cc: Hui Zhu , gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-02/txt/msg00053.txt.bz2 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 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 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 >