a question about gdb and simulator

a question about gdb and simulator

[liu lijuan]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb2312; format=flowed, Size: 1298 bytes --]


    We are doing graduate design about SOC design tool, and we want to 
extend GNU debugger¡¯s some functions, and do a simulator and debugger 
environment. We use SystemC to simulate the procedure of CPU simulator, and 
this simulator is a part of hardware system.  During the simulation, CPU 
simulator needs a soft debugger. We want to use gdb as its debugger. We 
know that gdb supports built-in CPU simulator, but our simulator isn¡¯t 
built-in. But we don¡¯t know how gdb exchange information with built-in 
simulator and control the run of built-in CPU simulator. On this condition, 
we intend to apply the communication method between gdb and built-in CPU 
simulator to our design. Our simulator doesn¡¯t work as gdb¡¯s ISS , and 
also doesn¡¯t run in remote manner, therefore we think ¡°gdb remote serial 
protocol¡± can not be used in our design. Because our CPU simulator run in 
local manner (simulator and gdb run in the same machine), we think the same 
mechanism may be used in our design.
    If you have time, can you help us and provide us some reference about 
our work?
    Thanks a lot!



_________________________________________________________________
ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£  http://www.hotmail.com  

Re: a question about gdb and simulator

[Andrew Cagney]

> 
>    We are doing graduate design about SOC design tool, and we want to extend GNU debugger隆炉s some functions, and do a simulator and debugger environment. We use SystemC to simulate the procedure of CPU simulator, and this simulator is a part of hardware system.  During the simulation, CPU simulator needs a soft debugger. We want to use gdb as its debugger. We know that gdb supports built-in CPU simulator, but our simulator isn隆炉t built-in. But we don隆炉t know how gdb exchange information with built-in simulator and control the run of built-in CPU simulator. On this condition, we intend to apply the communication method between gdb and built-in CPU simulator to our design. Our simulator doesn隆炉t work as gdb隆炉s ISS , and also doesn隆炉t run in remote manner, therefore we think 隆掳gdb remote serial protocol隆卤 can not be used in our design. Because our CPU simulator run in local manner (simulator and gdb run in the same machine), we think the same mechanism may be used in our desig
n.
>    If you have time, can you help us and provide us some reference about our work?
>    Thanks a lot!

Assuming you have the GDB sources in front of you, look at the file
"src/include/gdb/remote-sim.h".  It defines the GDB-SIM interfaces that
GDB currently uses.

Also, I'd not dismiss the "remote" method.  Some simulators use that
interface as well.

Andrew

Re: a question about gdb and simulator

[Andrew Cagney]

>>
>>Assuming you have the GDB sources in front of you, look at the file
>>"src/include/gdb/remote-sim.h". It defines the GDB-SIM interfaces that
>>GDB currently uses.
>>
>>Also, I'd not dismiss the "remote" method. Some simulators use that
>>interface as well.
> 
>> >Andrew
> Thank you very much! It is very important to us. But I have some questions
> on remote debugging. Does it include the debugging of built-in cpu simulator
> by inputting "target sim" and the debugging using remote serial protocol to
> communicate by inputting "target remote xxxx"?

If the simulator is not built-in, you would any of:

(gdb) target remote host:port
(gdb) target remote |simulator
(gdb) target extended-remote <same-choices>

The option `|simulator' is probably the most useful.  It talks remote
protocol on stdin/stdout.

Andrew

Re: a question about gdb and simulator

[Fyles, Matthew]

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.