From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11259 invoked by alias); 21 Jan 2009 22:15:22 -0000 Received: (qmail 11249 invoked by uid 22791); 21 Jan 2009 22:15:21 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_102,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 21 Jan 2009 22:15:15 +0000 Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id n0LMFDu8024881 for ; Wed, 21 Jan 2009 14:15:13 -0800 Received: from rv-out-0708.google.com (rvfb17.prod.google.com [10.140.179.17]) by wpaz37.hot.corp.google.com with ESMTP id n0LMEiVk003175 for ; Wed, 21 Jan 2009 14:15:11 -0800 Received: by rv-out-0708.google.com with SMTP id b17so4156421rvf.40 for ; Wed, 21 Jan 2009 14:15:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.210.13 with SMTP id m13mr105168rvq.181.1232576109574; Wed, 21 Jan 2009 14:15:09 -0800 (PST) In-Reply-To: References: Date: Wed, 21 Jan 2009 22:15:00 -0000 Message-ID: Subject: Re: The right way to port GDB to a new architecture From: Doug Evans To: Andreas Olofsson Cc: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: 2009-01/txt/msg00149.txt.bz2 On Wed, Jan 21, 2009 at 1:56 PM, Andreas Olofsson wrote: > Hi Doug, > > Thanks for the reply. Here's a follow up question for you (or others). > > It sounds like a stub is the way to go for remote debugging. (no OS > planned at this point) If there's no OS planned (at least for now) then I'd say a stub is the way to go. > We actually have a functioning cgen generated simulator already but it > is not yet integrated with gdb. Some of the simulators distributed > with gdb (like the m32r) seem to be generated from cgen as well. What > would be the effort in creating the necessary interfaces between the > cgen based simulator and gdb. I am hoping for almost zero.:-) For reference sake, most gdb simulators use the same (non-isa related) infrastructure, to varying degrees. It's in sim/common. Gluing the simulator to gdb is mostly a matter of cut-n-paste-n-tweak. The interface is defined in include/gdb/remote-sim.h. Several of those functions are already provided by sim/common. For the remaining ones, take an existing simulator (m32r is fine for this purpose) and ctudy its sim-if.c file (e.g. sim/m32r/sim-if.c). On the GDB side it's also cut-n-paste-n-tweak. From gdb/configure.tgt: m32r*-*-*) # Target: Renesas m32r processor gdb_target_obs="m32r-tdep.o monitor.o m32r-rom.o dsrec.o \ remote-m32r-sdi.o" gdb_sim=../sim/m32r/libsim.a ;; The simulator related portion is (of course) the setting of gdb_sim. Set this to ../sim//libsim.a. Setting this will cause remote-sim.o to be linked into gdb which will in turn enable the simulator target from the command line. Replace m32r-tdep.o with -tdep.o. You probably don't need the equivalent of m32r-rom.o and remote-m32r-sdi.o, so delete those. dsrec.o is a target independent file for downloading s-records. Include it if your rom monitor (or whatever) supports s-record downloads. > > Andreas > > > > On Tue, Jan 13, 2009 at 2:30 PM, Doug Evans wrote: >> On Tue, Jan 13, 2009 at 7:39 AM, Andreas Olofsson >> wrote: >>> I have been reading through the GDB documentation and I need some >>> advice on the best approach to porting GDB to a new architecture >>> before I dive into the porting process.. >>> >>> Describing the architecture doesn't seem too bad and is well described >>> in Jeremy Bennett's document "Howto: Porting the GNU debugger". How >>> to actually communicate with the target looks to be more of a >>> challenge and there seem to be a number of different approaches. >>> >>> Possible approaches(we already have bfd, binutils, gcc, and all the >>> other stuff ported): >>> >>> 1.) Use cgen or sid to generate a gdb compliant simulator and link in >>> the simulator library. Since we will need the remote debugging option >>> eventually, I am thinking that integrating a cgen based simulator with >>> GDB would be extra work and I would like to skip this step if >>> possible. >> >> If you don't *need* a simulator, skip it. Often a simulator is >> written because it's an easier vehicle for testing gcc (and gdb to >> some extent). >> >>> 2.) Write a stub for the target and use remote serial protocol. The >>> included stubs in the distribution are quite old? Is this no longer a >>> preferred method? >> >> What kind of architecture + o/s? Is it an embedded system? Does it >> run some o/s? The stubs are mostly intended for embedded systems >> where the device isn't running an o/s, per se, and the application >> "owns" the device. The stub is linked into the application to be >> debugged and inserts handlers for various interrupts - not something >> one can typically do if running on a typical o/s. They may be old but >> there's not much too them, if your system is similar they could still >> be good boilerplate. >> >>> >>> 3.) Port gdbserver to the new architecture. Is it a requirement to >>> have linux running on the target? Based on the ports I have seen in >>> GDB it would seem to be the case? Why doesn't the ARM have a stub for >>> example? I can't imagine you have to run linux on an arm based device >>> to be able use remote GDB? >> >> Porting gdbserver doesn't require linux, linux is just the canonical >> example. gdbserver is for situations where the remote target is >> running a multitasking o/s, and it serves as a proxy for gdb. A lot >> of the porting work is similar to the work one must do to port gdb >> itself. >> >> You are correct, you don't need linux to debug arm based devices, but >> it depends on the device. For example, if the arm based device is >> running linux then a gdbserver port is a reasonable thing to have. >> The arm doesn't have a stub only because I suspect no one has >> contributed one to the gdb tree. >> >> For reference sake (meaning, here's some data, use it if you get >> stuck, but I suspect most of the following won't be helpful) ... >> You might also look at rda, http://sourceware.org/rda/, but it's a bit >> old too. There are also stubs in the libgloss part of newlib >> (http://sourceware.org/newlib/). Plus ecos has some gdb stubs >> (http://ecos.sourcware.org), although ecos is a big package itself and >> extracting the stubs out may be problematic. >> >>> >>> 4.) Another approach? >>> >>> If we assume that the target is not running linux, what would be a >>> good starting point to work from: m32r? >> >> m32r is my favorite starting point, but the reasons aren't technical. :-) >> I would pick an architecture that is reasonably similar to yours and >> go from there. >> What architecture (+ o/s if any) are you porting to? >> >