From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23040 invoked by alias); 15 Aug 2011 15:26:10 -0000 Received: (qmail 23028 invoked by uid 22791); 15 Aug 2011 15:26:09 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mms1.broadcom.com (HELO mms1.broadcom.com) (216.31.210.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 15 Aug 2011 15:25:54 +0000 Received: from [10.9.200.133] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 15 Aug 2011 08:31:39 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from mail-irva-13.broadcom.com (10.11.16.103) by IRVEXCHHUB02.corp.ad.broadcom.com (10.9.200.133) with Microsoft SMTP Server id 8.2.247.2; Mon, 15 Aug 2011 08:25:28 -0700 Received: from [10.177.73.61] (unknown [10.177.73.61]) by mail-irva-13.broadcom.com (Postfix) with ESMTP id 1A8CA74D03 for ; Mon, 15 Aug 2011 08:25:45 -0700 (PDT) Message-ID: <4E493A79.3060002@broadcom.com> Date: Mon, 15 Aug 2011 15:26:00 -0000 From: "Andrew Burgess" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: gdb@sourceware.org Subject: Re: What role does gdb/remote.c play? References: <54475b.156ef.131ccb300f5.Coremail.yongyong.yang@ia.ac.cn> <201108151109.56890.pedro@codesourcery.com> <201108151432.33454.pedro@codesourcery.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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/msg00050.txt.bz2 On 15/08/2011 16:09, Triple Yang wrote: > 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. The commands "target remote" and "break" are different, the "target remote" is used to pick which "struct target_ops" is used to talk to a target, commands like "break" use the functions linked into the "struct target_ops" in order to do debugging stuff with your target. The remote in "target remote" comes from the to_shortname field of the struct target_ops. If you have created your own struct target_ops then you should fill this field in with a unique target name, say xxx, you can then say "target xxx" and gdb will use your struct target_ops to talk to the target. > 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. The calls to _initialize_ build up the total list of all possible targets. Just having a target in the list doesn't mean it's being used, a target type is selected when you issue the target command to gdb. Andrew