From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15887 invoked by alias); 13 Jan 2009 15:40:38 -0000 Received: (qmail 15878 invoked by uid 22791); 13 Jan 2009 15:40:37 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=BAYES_00,J_CHICKENPOX_102,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from wa-out-1112.google.com (HELO wa-out-1112.google.com) (209.85.146.180) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 13 Jan 2009 15:40:01 +0000 Received: by wa-out-1112.google.com with SMTP id v33so28898wah.24 for ; Tue, 13 Jan 2009 07:39:59 -0800 (PST) Received: by 10.115.73.20 with SMTP id a20mr20377809wal.1.1231861199472; Tue, 13 Jan 2009 07:39:59 -0800 (PST) Received: by 10.114.145.17 with HTTP; Tue, 13 Jan 2009 07:39:59 -0800 (PST) Message-ID: Date: Tue, 13 Jan 2009 15:40:00 -0000 From: "Andreas Olofsson" To: gdb@sourceware.org Subject: The right way to port GDB to a new architecture MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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/msg00063.txt.bz2 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? Andreas