This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RE: What should a CPU simulator support?
- From: "Robert Norton" <rnorton at broadcom dot com>
- To: "Jim Blandy" <jimb at codesourcery dot com>, "s88" <dave dot tw at gmail dot com>
- Cc: "Wenbo Yang" <wenbo dot yang at simplnano dot com>, gdb at sourceware dot org
- Date: Fri, 6 Jul 2007 03:26:48 -0700
- Subject: RE: What should a CPU simulator support?
- References: <468C57AE.8020801@simplnano.com> <m3d4z64q8w.fsf@codesourcery.com> <c9d32f760707051300r192ea70bj3edcfc00892c5714@mail.gmail.com> <m3ejjmfsfk.fsf@codesourcery.com>
> -----Original Message-----
> From: gdb-owner@sourceware.org
> [mailto:gdb-owner@sourceware.org] On Behalf Of Jim Blandy
> Sent: 05 July 2007 22:32
> To: s88
> Cc: Wenbo Yang; gdb@sourceware.org
> Subject: Re: What should a CPU simulator support?
> <snip>
> 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.
Is this still the recommended way of making a built-in simulator? I
noticed when upgrading our port that the api for simulator implemented
breakpoints has been removed! We're not interested in implementing soft
breakpoints so I had to resurrect this support in remote-sim.c.
Cheers,
Robert