From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25595 invoked by alias); 15 Aug 2011 15:46:19 -0000 Received: (qmail 25587 invoked by uid 22791); 15 Aug 2011 15:46:16 -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 15:46:02 +0000 Received: by fxg9 with SMTP id 9so4271584fxg.0 for ; Mon, 15 Aug 2011 08:46:01 -0700 (PDT) Received: by 10.223.85.145 with SMTP id o17mr5744499fal.16.1313423159293; Mon, 15 Aug 2011 08:45:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.83.2 with HTTP; Mon, 15 Aug 2011 08:45:38 -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 15:46: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/msg00053.txt.bz2 On 15 August 2011 17:09, Triple Yang wrote: > 2011/8/15 Pedro Alves : >> On Monday 15 August 2011 12:51:11, Triple Yang wrote: >> >>> Then, if I want to create a new remote target, should I just modify >>> remote.c or reuse codes in it? >> >> I don't know what your new target does, so I can't answer that for you. >> >>> How do I map command 'target remote' to the new target I created? >> >> You don't. =C2=A0Do you _really_ need to implement a new target in gdb? >> Why not teach the remote end the RSP instead? =C2=A0Then you can >> use "target remote", without adding new code to gdb. >> > > 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. > To "teach the remote end the RSP instead", what needs to be done? On remote system do create a listening TCP socket and implement processing the remote protocol commands [1]. The gdbserver does that for several architectures and can serve as an inspiration. [1] http://sourceware.org/gdb/current/onlinedocs/gdb/Remote-Protocol.html --=20 Petr Hluzin