From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15957 invoked by alias); 13 Jan 2009 17:59:33 -0000 Received: (qmail 15949 invoked by uid 22791); 13 Jan 2009 17:59:32 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_102 X-Spam-Check-By: sourceware.org Received: from smtp.idnet.com (HELO smtp-out.idnet.com) (212.69.36.238) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 13 Jan 2009 17:58:53 +0000 Received: from localhost (unknown [127.0.0.1]) by smtp-out.idnet.com (Postfix) with ESMTP id F41C62D7C60 for ; Tue, 13 Jan 2009 17:58:49 +0000 (UTC) Received: from smtp-out.idnet.com ([127.0.0.1]) by localhost (smtp-out.idnet.com [127.0.0.1]) (amavisd-new, port 10040) with LMTP id v4w+X5Yp9FOw for ; Tue, 13 Jan 2009 17:58:49 +0000 (GMT) Received: from mail.idnet.net.uk (mail.idnet.net.uk [212.69.36.63]) by smtp-out.idnet.com (Postfix) with ESMTP id 92A752DFC1A for ; Tue, 13 Jan 2009 17:58:46 +0000 (GMT) Received: from [91.135.5.64] by mail.idnet.net.uk (GMS 15.01.3664/NU3963.00.7ca42f0c) with ESMTP id fylddpba for gdb@sourceware.org; Tue, 13 Jan 2009 17:58:42 +0000 Subject: Re: The right way to port GDB to a new architecture From: Jeremy Bennett Reply-To: jeremy.bennett@embecosm.com To: Andreas Olofsson Cc: gdb@sourceware.org In-Reply-To: References: Content-Type: text/plain Date: Tue, 13 Jan 2009 17:59:00 -0000 Message-Id: <1231869524.2944.210.camel@thomas> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-AuthenticatedSender: jeremy.bennett.embecosm.com@idnet.net.uk 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/msg00064.txt.bz2 On Tue, 2009-01-13 at 10:39 -0500, 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. > > 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? > > 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? > > 4.) Another approach? > > If we assume that the target is not running linux, what would be a > good starting point to work from: m32r? Hi Andreas, Glad you liked the application note. There is now another one on writing an RSP server. I'm hoping to get the key parts incorporated into the mainstream GDB manual before long, in the meantime it's here: http://www.embecosm.com/download/ean4.html The example I used for the OpenRISC 1000 is bare metal, not Linux (even though it uses the OpenRISC Linux toolchain), so you could use that as a starting point. If you don't intend running GDB on the target, you'll need a remote connection at some time, so developing the RSP server side makes sense. The example I used in the application note was talking to a simulator rather than real hardware, so this is a feasible approach. HTH, Jeremy -- Tel: +44 (1202) 416955 Cell: +44 (7970) 676050 SkypeID: jeremybennett Email: jeremy.bennett@embecosm.com Web: www.embecosm.com