From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26849 invoked by alias); 15 Aug 2011 15:28:31 -0000 Received: (qmail 26834 invoked by uid 22791); 15 Aug 2011 15:28:30 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 15 Aug 2011 15:28:13 +0000 Received: (qmail 2870 invoked from network); 15 Aug 2011 15:28:12 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 15 Aug 2011 15:28:12 -0000 From: Pedro Alves To: gdb@sourceware.org Subject: Re: What role does gdb/remote.c play? Date: Mon, 15 Aug 2011 15:28:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-10-generic; KDE/4.7.0; x86_64; ; ) Cc: Triple Yang References: <54475b.156ef.131ccb300f5.Coremail.yongyong.yang@ia.ac.cn> <201108151432.33454.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201108151628.08465.pedro@codesourcery.com> 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/msg00051.txt.bz2 On Monday 15 August 2011 16:09:44, 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. Do you _really_ need to implement a new target in gdb? > > Why not teach the remote end the RSP instead? Then 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. New architecture support does not require a new target_ops instance. For example, you can connect gdb to all of arm-linux, powerpc-linux, mips-linux, x86-linux, x86-windows, etc. gdbservers all through the same "target remote" (remote.c) command, all from the same build of gdb hosted on e.g., x86-linux. Architecture support should be host independent, and implemented on the *-tdep.c files. E.g., start looking at arm-tdep.c, at arm_gdbarch_init. "gdbarch" is the structure that knows everything about an architecture. > To "teach the remote end the RSP instead", what needs to be done? You need to teach what you're connecting to, to support the RSP protocol. Teach it the memory read/write packets, the register read/write packets, the step/continue packets, stop replies, etc.. Try connecting to a gdbserver running on your computer, with $ gdbserver :9999 /foo/program/to/debug on another shell: $ gdb /foo/program/to/debug ... (gdb) set debug remote 1 (gdb) tar remote :9999 and you'll see the RSP traffic. I think Jeremy Bennett's howto is likely to be of help: http://www.embecosm.com/appnotes/ean4/embecosm-howto-rsp-server-ean4-issue-2.html > The Question is, when I created my own "struct target_ops" object and > initialized it properly, then added it to targetlist, I could expect > it would respond to commands like target remote and break. Your expectation is wrong, sorry. It will react to "target FOO", with FOO being the target's short name, as in the list in one of my previous emails: $ grep "to_shortname = " src/gdb/remote*.c remote.c: remote_ops.to_shortname = "remote"; remote.c: extended_remote_ops.to_shortname = "extended-remote"; remote-m32r-sdi.c: m32r_ops.to_shortname = "m32rsdi"; remote-mips.c: mips_ops.to_shortname = "mips"; remote-mips.c: pmon_ops.to_shortname = "pmon"; remote-mips.c: ddb_ops.to_shortname = "ddb"; remote-mips.c: rockhopper_ops.to_shortname = "rockhopper"; remote-mips.c: lsi_ops.to_shortname = "lsi"; remote-sim.c: gdbsim_ops.to_shortname = "sim"; > As I've mentioned in a previous mail, current_target holds the value > specified in remote.c rather than my own remote-XXX.c. I guess the > expected value is overrided in init.c (which is a generated file > during building) since _initialize_remote() is called after calling > _initialize_remote_XXX(). It is easy to find an ugly and offensive way > to avoid that situation. But I tend to believe there are some clean > and pretty means to do that and I don't know yet. There's no means for that, because that's the wrong thing to do, sorry. -- Pedro Alves