From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9713 invoked by alias); 5 Feb 2010 06:50:45 -0000 Received: (qmail 9705 invoked by uid 22791); 5 Feb 2010 06:50:44 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-px0-f175.google.com (HELO mail-px0-f175.google.com) (209.85.216.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 05 Feb 2010 06:50:40 +0000 Received: by pxi5 with SMTP id 5so3905084pxi.12 for ; Thu, 04 Feb 2010 22:50:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.143.153.39 with SMTP id f39mr1454735wfo.60.1265352639072; Thu, 04 Feb 2010 22:50:39 -0800 (PST) In-Reply-To: <23c0f921002041138k1d989b9cs8423911108499331@mail.gmail.com> References: <23c0f921002041138k1d989b9cs8423911108499331@mail.gmail.com> From: Hui Zhu Date: Fri, 05 Feb 2010 06:50:00 -0000 Message-ID: Subject: Re: Switching architectures from a remote target To: Robert Barnes Cc: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes 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/msg00026.txt.bz2 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 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 >