From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15711 invoked by alias); 7 Jun 2012 19:18:45 -0000 Received: (qmail 15698 invoked by uid 22791); 7 Jun 2012 19:18:43 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,TW_QE X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 07 Jun 2012 19:18:30 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1SciE0-0003Ng-UJ from Maciej_Rozycki@mentor.com ; Thu, 07 Jun 2012 12:18:28 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Jun 2012 12:18:28 -0700 Received: from [172.30.1.189] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Thu, 7 Jun 2012 20:18:26 +0100 Date: Thu, 07 Jun 2012 19:18:00 -0000 From: "Maciej W. Rozycki" To: Daniel Jacobowitz CC: Subject: Re: GDB/remote: RSP `g' packet size, advice sought In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 8BIT 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: 2012-06/txt/msg00043.txt.bz2 On Tue, 5 Jun 2012, Daniel Jacobowitz wrote: > Don't take this reply too seriously, it's been a while. No worries, thanks for speaking out. > > This is because the 24Kc does not support the FPU and the 24Kf does, and > > hence the latter produces a longer `g' reply packet that includes the > > extra FPU state.  However the remote backend has already shrunk its `g' > > packet buffer size when talking to the 24Kc and cannot expand it back. > > The only way to recover is to restart GDB from scratch that can be > > annoying. > > > >  I have tracked down the cause to be the way the remote backend > > initialises the `g' packet size.  It's only done in init_remote_state that > > is called once, when gdbarch data is initialized.  The initial size is > > calculated based on the maximum number of registers supported by the > > architecture: > > Why should those two connections have the same gdbarch? Is qemu > neither returning an XML architecture description, nor a g packet size > that we can use to guess an architecture with one of the registered > g-packet guessing handlers? QEMU doesn't provide an XML architecture description AFAICT; this would be very much desirable to access other important CP0 registers (e.g. EPC -- crucial to debug exception causes) if nothing else, but as it stands this has a scalability problem for MIPS as you may know. As to the packet size guess, I have to admit I wasn't aware that it should be able to cure the problem -- I'll have a look into it and see if there's anything missing. Although proliferating these guesses too much is only going to cause confusion I am afraid. > That's the actual problem - we shouldn't need to reset things within a > gdbarch. Some day we should be able to connect to both of these CPUs > at once. Hopefully we'll have come up with a better XML scheme by then though; we'll still have to handle legacy stubs though. Thanks for the hint. Maciej