From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28919 invoked by alias); 29 May 2003 18:54:00 -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 28912 invoked from network); 29 May 2003 18:53:59 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.131) by sources.redhat.com with SMTP; 29 May 2003 18:53:59 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 059592B2F; Thu, 29 May 2003 14:53:53 -0400 (EDT) Message-ID: <3ED65740.9020306@redhat.com> Date: Thu, 29 May 2003 18:54:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Elena Zannoni Cc: Richard.Earnshaw@arm.com, "Svein E. Seldal" , gdb@sources.redhat.com Subject: Re: Porting advice or documentation request References: <3ED53E58.5070502@solidas.com> <200305290949.h4T9nso00798@pc960.cambridge.arm.com> <16086.10689.70706.173163@localhost.redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00399.txt.bz2 > Richard Earnshaw writes: > > > Hi all, > > > > > > I'm working on this new gdb port, and more than often I'm stuck. I have > > > been told that the d10v port is the most authorative template for how > > > new targets should be written. Unfortunately it is impossible to learn > > > anything about the d10v's hardware architecture on the net, so I find it > > > a bit difficult to template from. > > > > I can sympathise. I've tried on a couple of occasions to update the ARM > > target to use the new interfaces and I've repeatedly run into situations > > where the GDB's abstraction model is just not obvious from staring at the > > code. > > > > Andrew, I think we really need a 10,000 ft view document on gdb's internal > > architecture to complement the list of macros that a target can define... For a 10 000' view there's the multi-arch white paper, and posts such as: Ref: cooked regcache -> frame (follow the links in it) http://sources.redhat.com/ml/gdb/2003-05/msg00287.html Ref: WIP: Register doco http://sources.redhat.com/ml/gdb/2002-07/msg00202.html One thing that is missing, though, is a migration strategy that is known to work (like the convert to multi-arch doco). Can I suggest starting with a set_gdbarch_deprecated_* method and working down (see gdbarch.h for the replacement). I think trying to start from the other end - trying to eliminate all instances of something like deprecated_registers[] say - will run into real problems. > I think checking out the new i386 frame branch could help here > too. Mark updated the i386 to use the new frame stuff, so that could > be used as example. Yes, definitly. I've been told that a third architecture is lurking in the wings. Andrew