From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29486 invoked by alias); 12 May 2002 14:20:18 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 29476 invoked from network); 12 May 2002 14:20:17 -0000 Received: from unknown (HELO fw-cam.cambridge.arm.com) (193.131.176.3) by sources.redhat.com with SMTP; 12 May 2002 14:20:17 -0000 Received: by fw-cam.cambridge.arm.com; id PAA07023; Sun, 12 May 2002 15:20:15 +0100 (BST) Received: from unknown(172.16.1.2) by fw-cam.cambridge.arm.com via smap (V5.5) id xma006898; Sun, 12 May 02 15:19:30 +0100 Received: from cam-mail2.cambridge.arm.com (cam-mail2.cambridge.arm.com [172.16.1.91]) by cam-admin0.cambridge.arm.com (8.9.3/8.9.3) with ESMTP id PAA26588; Sun, 12 May 2002 15:19:30 +0100 (BST) Received: from sun18.cambridge.arm.com (sun18.cambridge.arm.com [172.16.2.18]) by cam-mail2.cambridge.arm.com (8.9.3/8.9.3) with ESMTP id PAA29377; Sun, 12 May 2002 15:19:29 +0100 (BST) Message-Id: <200205121419.PAA29377@cam-mail2.cambridge.arm.com> To: Andrew Cagney cc: Richard.Earnshaw@arm.com, gdb@sources.redhat.com Reply-To: Richard.Earnshaw@arm.com Organization: ARM Ltd. X-Telephone: +44 1223 400569 (direct+voicemail), +44 1223 400400 (switchbd) X-Fax: +44 1223 400410 X-Address: ARM Ltd., 110 Fulbourn Road, Cherry Hinton, Cambridge CB1 9NJ. X-Url: http://www.arm.com/ Subject: Re: ARM and virtual/raw registers In-reply-to: Your message of "Sat, 11 May 2002 17:52:41 EDT." <3CDD92A9.70401@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 12 May 2002 07:20:00 -0000 From: Richard Earnshaw X-SW-Source: 2002-05/txt/msg00121.txt.bz2 > The remote target is more than technically broken. > I'm glad we agree on something then ;-) > GDB is a slave to the remote protocol. The remote protocol is what > decides the layout of the raw register cache and that cache layout > depends on what ever the remote target and GDB once, long ago, > co-conspired. You can't touch the raw registers without breaking GDB's > ability to debug a remote target. The MIPS, for instance, has more > remote protocol formats than I've had hot dinners. Every different MIPS > configuration has a different, hard wired, remote protocol register buffer. > > BTW, the reason I mention i387-tdep.c is that I think it is an example > of where target side manipulation can go wrong. The i387-tdep code > doesn't just massage values, it instead completly re-orders the register > cache so that it contains the registers in i387 stack order. That, in > turn, lead to all sorts of bugs when trying to save/restore the i387 > registers. If this were re-implemented today, I think it the register > buffer would be would left in i387 save order, instead using > register_{read,write} (they were not available at the time). Having either the debug-info register numbers or a single target impose an order on the regcache is broken. Consider the case where we have two target interfaces that need to mandate different orderings; clearly one of them must fail. Similarly, having the debug-info mandate an ordering is equally broken -- consider two ABIs which use different numbering in the debug info. Clearly, the only way to solve this is to have mapping layers, at least in concept, at each interface. Then the tdep code is free to select any ordering it likes in the cache; typically an ordering that will lead to greatest efficiency. A colleague of mine once commented: "There's very few software problems that can't be solved with an extra layer of indirection." This is clearly one that can... > I think, under your model, this would be flaged as a no-no - there being > no technical reason for laying the registers out in a way other than > according to i387 save order. See the WIP code I posted just now. R.