From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24019 invoked by alias); 11 May 2002 14:05:46 -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 24012 invoked from network); 11 May 2002 14:05:45 -0000 Received: from unknown (HELO fw-cam.cambridge.arm.com) (193.131.176.3) by sources.redhat.com with SMTP; 11 May 2002 14:05:45 -0000 Received: by fw-cam.cambridge.arm.com; id PAA24529; Sat, 11 May 2002 15:05:43 +0100 (BST) Received: from unknown(172.16.1.2) by fw-cam.cambridge.arm.com via smap (V5.5) id xma024423; Sat, 11 May 02 15:05:21 +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 PAA13944; Sat, 11 May 2002 15:05:20 +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 PAA15949; Sat, 11 May 2002 15:05:20 +0100 (BST) Message-Id: <200205111405.PAA15949@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 "Fri, 10 May 2002 15:07:49 EDT." <3CDC1A85.4090603@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 11 May 2002 07:05:00 -0000 From: Richard Earnshaw X-SW-Source: 2002-05/txt/msg00114.txt.bz2 > >> Now obviously, in order to do all this correctly the stack-frame groveller will have to record the information as it unwinds the stack in some private data; but creating this information is part of the stack-unwinding process. > > > > > Yes. The arm would need to implement a custom get_saved_register() architecture method. > > > > Rather than normalize the registers on the way in. Consider normalizing them them on the way out via a pseudo. Doing this would mean that the raw register wouldn't be directly visible and the layer below regcache wouldn't need to normalize anything. > > [to expand a little] > > Two target side interfaces (at least) don't have mechanisms for > re-aranging (normalizing) registers on the way in: > - sim > - remote > I suspect that at least short term, doing everything on the gdb-core > side will be easier. No, it wouldn't. Because then the gdb-core side would have to know *how* the target was connected. That is, the normalization function becomes f(value,target-vector); which complicates things vastly. > Having the very raw data in the cache may also prove better for > debugging - both the raw (in cache) and the normalized (via register > read/write) formats are available. Perhaphs also look at the i387 which > normalizes things on the way in (and its bug count). Let me try and clarify the model that I think we have in gdb; maybe that will help to explain why I think doing it on the gdb-core side is incorrect. GDB has three main vectors, but only two are interesting in this case (the third being the UI). The target vector is the lowest level, it provides a virtual abstraction of the processor -- registers, memory etc and methods for recovering/changing their contents and generally manipulating the machine (stepping, breakpoints, etc). The target vector should present a substantially uniform view of the processor regardless of the method used to connect to it. Putting it another way, the target vector presents substantially the basic programmers' model of the CPU to the debugger. The gdbarch vector is, effectively, the ABI model applied to that virtual machine; it covers the mapping rules that were used by the compiler when it produced the machine code for the user's program: procedure call standards, layout of record types, symbolic information etc. It knows, for example, when a double for the variable X is in register F0: it doesn't want to have to worry about how F0 is being recovered from the physical machine -- in particular it doesn't want to know about how that might vary across the various target connections -- that's the responsibility of the target vector. As to whether the sim or remote targets can be made to support this model cleanly, I'm not to worried about sim -- we can always fix this in sim/arm/wrapper.c, the layer that interfaces between gdb and the simulator so that it presents the virtual CPU model directly. I don't know enough about remote.c at this time to know what the problems are there, but I suspect that this one will be the least of my worries when I want to start adding support for the banked registers as well. However, if these targets can't present the processor abstraction cleanly, then they are technically broken ;-) R.