From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17361 invoked by alias); 13 Jan 2009 19:31:30 -0000 Received: (qmail 17352 invoked by uid 22791); 13 Jan 2009 19:31:30 -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; Tue, 13 Jan 2009 19:30:59 +0000 Received: from spaceape9.eur.corp.google.com (spaceape9.eur.corp.google.com [172.28.16.143]) by smtp-out.google.com with ESMTP id n0DJUuTg001027 for ; Tue, 13 Jan 2009 11:30:57 -0800 Received: from rv-out-0506.google.com (rvfb25.prod.google.com [10.140.179.25]) by spaceape9.eur.corp.google.com with ESMTP id n0DJUOPM031652 for ; Tue, 13 Jan 2009 11:30:54 -0800 Received: by rv-out-0506.google.com with SMTP id b25so154489rvf.39 for ; Tue, 13 Jan 2009 11:30:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.66.16 with SMTP id t16mr15445870rvk.103.1231875053645; Tue, 13 Jan 2009 11:30:53 -0800 (PST) In-Reply-To: References: Date: Tue, 13 Jan 2009 19:31: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/msg00065.txt.bz2 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?