From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22526 invoked by alias); 15 Aug 2011 20:13:04 -0000 Received: (qmail 22516 invoked by uid 22791); 15 Aug 2011 20:13:03 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-fx0-f41.google.com (HELO mail-fx0-f41.google.com) (209.85.161.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 15 Aug 2011 20:12:47 +0000 Received: by fxg9 with SMTP id 9so4441487fxg.0 for ; Mon, 15 Aug 2011 13:12:46 -0700 (PDT) Received: by 10.223.56.79 with SMTP id x15mr5938241fag.130.1313439106125; Mon, 15 Aug 2011 13:11:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.83.2 with HTTP; Mon, 15 Aug 2011 13:11:26 -0700 (PDT) In-Reply-To: References: <54475b.156ef.131ccb300f5.Coremail.yongyong.yang@ia.ac.cn> <201108151109.56890.pedro@codesourcery.com> <201108151432.33454.pedro@codesourcery.com> From: =?UTF-8?B?UGV0ciBIbHV6w61u?= Date: Mon, 15 Aug 2011 20:13:00 -0000 Message-ID: Subject: Re: What role does gdb/remote.c play? To: Triple Yang Cc: gdb@sourceware.org, Pedro Alves Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: 2011-08/txt/msg00057.txt.bz2 On 15 August 2011 20:20, Triple Yang wrote: > 2011/8/15 Petr Hluz=C3=ADn : >> On 15 August 2011 17:09, Triple Yang wrote: >>> Yes, because I am trying porting GDB to a new architecture prototype. >>> Implementing a new target seems to be the only way to achieve the >>> purpose. >> >> If your users want to debug programs running on a remote >> machine/device then you can either: >> A: override "target remote" (or other target) implementation in GDB >> and use custom communication or >> B: use GDB's remote protocol, modify gdbserver sources and write your >> own handling or >> C: use GDB's remote protocol and write your own parsing and handling >> >> The option A is not recommended (see Pedro Alves) because it either >> means you will be distributing your own GDB or be stuck to FSF release >> schedule. Also users of older gdbs will not be able to connect (plus >> users will get misleading diagnostic). And there is a lot of code in >> gdb and many ways to get lost. >> >> For options B and C the user would type "target remote" and it will >> behave the way users expect from other archs (as the case may be), >> what tutorials describe and what IDEs do well. >> > > So in option B or C, will reusing codes in remote.c be satisfying? > (Thus I may save some time in writing codes parsing/wrapping RSP > packets.) No, you cannot reuse code in [1]. GDB uses the code to format commands and parse responses. You can reuse code of gdbserver in [2]. This directory includes the code for parsing commands from GDB and formatting responses. However there are many more implementations of a GDB remote monitor/stub in the world, the gdbserver is just one of them. [1] http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/remote.c?cvsroot=3Dsrc [2] http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/gdbserver/?cvsroot=3Ds= rc --=20 Petr Hluzin