From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32193 invoked by alias); 15 Aug 2011 17:54:42 -0000 Received: (qmail 32177 invoked by uid 22791); 15 Aug 2011 17:54:40 -0000 X-SWARE-Spam-Status: No, hits=-0.9 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Received: from mail-gx0-f169.google.com (HELO mail-gx0-f169.google.com) (209.85.161.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 15 Aug 2011 17:54:24 +0000 Received: by gxk23 with SMTP id 23so3583060gxk.0 for ; Mon, 15 Aug 2011 10:54:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.176.130 with SMTP id b2mr13287781yhm.140.1313430863939; Mon, 15 Aug 2011 10:54:23 -0700 (PDT) Received: by 10.147.34.4 with HTTP; Mon, 15 Aug 2011 10:54:23 -0700 (PDT) In-Reply-To: References: <54475b.156ef.131ccb300f5.Coremail.yongyong.yang@ia.ac.cn> <201108151432.33454.pedro@codesourcery.com> <201108151628.08465.pedro@codesourcery.com> Date: Mon, 15 Aug 2011 17:54:00 -0000 Message-ID: Subject: Re: What role does gdb/remote.c play? From: Triple Yang To: gdb@sourceware.org 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/msg00055.txt.bz2 2011/8/15 Pedro Alves : > 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. =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. > > 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. =C2=A0Architecture support should be host > independent, and implemented on the *-tdep.c files. =C2=A0E.g., start loo= king > at arm-tdep.c, at arm_gdbarch_init. =C2=A0"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. =C2=A0Teach 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-issu= e-2.html > Besides his Howto: Porting the GNU Debugger and Howto: GDB Remote Serial Protocol, yes, Those materials have done a very good help to me. >> 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. =C2=A0It will react to "target FOO", wi= th > FOO being the target's short name, as in the list in one of my previous > emails: > > $ grep "to_shortname =3D " src/gdb/remote*.c > remote.c: =C2=A0remote_ops.to_shortname =3D "remote"; > remote.c: =C2=A0extended_remote_ops.to_shortname =3D "extended-remote"; > remote-m32r-sdi.c: =C2=A0m32r_ops.to_shortname =3D "m32rsdi"; > remote-mips.c: =C2=A0mips_ops.to_shortname =3D "mips"; > remote-mips.c: =C2=A0pmon_ops.to_shortname =3D "pmon"; > remote-mips.c: =C2=A0ddb_ops.to_shortname =3D "ddb"; > remote-mips.c: =C2=A0rockhopper_ops.to_shortname =3D "rockhopper"; > remote-mips.c: =C2=A0lsi_ops.to_shortname =3D "lsi"; > remote-sim.c: =C2=A0gdbsim_ops.to_shortname =3D "sim"; > Oh, God, I just didnot catch the essential. I was so careless. Forgive me. >> 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. > You are right, and I misunderstood. Thanks a lot for your detailed and informative explanation. Best regards. > -- > Pedro Alves >