From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9313 invoked by alias); 26 Feb 2003 18:04:46 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 9302 invoked from network); 26 Feb 2003 18:04:43 -0000 Received: from unknown (HELO ns2.uk.superh.com) (193.128.105.170) by 172.16.49.205 with SMTP; 26 Feb 2003 18:04:43 -0000 Received: from sh-uk-ex01.uk.w2k.superh.com (sh-uk-ex01 [192.168.16.17]) by ns2.uk.superh.com (8.11.6+Sun/8.11.6) with ESMTP id h1QHken02590 for ; Wed, 26 Feb 2003 17:46:40 GMT content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: a question about gdb and simulator X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 26 Feb 2003 18:04:00 -0000 Message-ID: <9FF3133289A7A84E81E2ED8F5E56B379537D91@sh-uk-ex01.uk.w2k.superh.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Fyles, Matthew" To: X-SW-Source: 2003-02/txt/msg00569.txt.bz2 This method has been achieved by connecting our simulations to GDB using the remote serial interface to a simulator running on the same machine as GDB. The remote serial interface is by far the most accurate way of connecting GDB to a simulated target as it allows the simulator to clock itself and act like a real CPU. Problems arise when bringing simulators that are built-in to GDB into environments such as systemC because systemC requires you to build your simulation as an executable. If you go down the road of having your simulation so tightly coupled with GDB you will have to link whatever libraries GDB uses into you systemC model. The system we use looks like this. GDB G tcp/ip remote <--> GDB Server <--> Shared memory <--> CPU simulator and debugger I/F In this case GDB is the standard GDB downloaded from the net sources, GDB server is an executable running on the same machine to handle GDB commands and the CPU simulator is our own in house simulator running on the same machine. In order to run this within systemC you need to link the shared object which gets built for our CPU simulator and debugger interface into the systemC environment and let it then compile an executable containing this functionality. You can then start up a systemC model and connect to it using the GDB target-remote command and you then have a software debugger running on your simulated hardware platform.