From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15331 invoked by alias); 5 Jul 2007 21:32:08 -0000 Received: (qmail 15321 invoked by uid 22791); 5 Jul 2007 21:32:08 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 05 Jul 2007 21:32:01 +0000 Received: (qmail 8357 invoked from network); 5 Jul 2007 21:31:59 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 5 Jul 2007 21:31:59 -0000 To: s88 Cc: "Wenbo Yang" , gdb@sourceware.org Subject: Re: What should a CPU simulator support? References: <468C57AE.8020801@simplnano.com> From: Jim Blandy Date: Thu, 05 Jul 2007 21:32:00 -0000 In-Reply-To: (dave.tw@gmail.com's message of "Fri, 6 Jul 2007 04:00:35 +0800") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2007-07/txt/msg00045.txt.bz2 s88 writes: > Let me try to define my question clearly. > > I have a ARM simulator. I want this simulator to be a target of the gdb. > And I write a gdb_stub for this simulator,too. > I'll use the remote debugging to connect this target (ARM simulator) in the way > of "target remote IP_ADDRESS:PORT". > So, I want to make sure if the ARM simulator support single instruction > execution. It should handle the gdb's command by the gdb stub? There are two ways for GDB to connect to a simulator: - You can make the simulator into a '.a' library, have it implement the interface in include/gdb/remote-sim.h, and link it directly with GDB. Then the GDB 'target sim' command will initialize the simulator, and subsequent 'run', 'continue', 'step' (etc.) commands will apply to it. This is simplest for the end user: no separate program to start up, no separate program file to find, and so on. - You can make the simulator into a server for the GDB remote protocol. Here, the interface to be implemented is described in the "Remote Protocol" appendix of the GDB manual. As that appendix says: For any COMMAND not supported by the stub, an empty response (`$#00') should be returned. That way it is possible to extend the protocol. A newer GDB can tell if a packet is supported based on that response. A stub is required to support the `g', `G', `m', `M', `c', and `s' COMMANDs. All other COMMANDs are optional. Note that the 's' (single-step) command is required. If you make your simulator speak the remote protocol on its stdin and stdout, then your user can use the new 'target remote | COMMAND' syntax to run the simulator, which simplifies things a bit.