public inbox for sid@sourceware.org
 help / color / mirror / Atom feed
From: Dave Brolley <brolley@redhat.com>
To: sid@sources.redhat.com
Subject: [patch][rfa]: Simulating and Debugging Multiple Processors
Date: Wed, 01 Aug 2001 14:29:00 -0000	[thread overview]
Message-ID: <3B6874C9.3030602@redhat.com> (raw)

Hi,

The attached patch adds two options to configrun-sid.in which enable 
loading programs into multiple cpus in a simulation and attaching 
multiple GDB debuggers to those cpus. The first option is:

--load PROCESSOR=NAME

o collects a mapping of processors to executables (may be specified more 
than once).
o reconciles $exec with any --load cpu=<name> which may have been  
specified (i.e. "cpu" specifically named on a --load option). The 
--load  option wins (with a warning) in case of conflict.
o generates a loader and mapper for each processor named 
<processor>-loader and <processor>-mapper respectively. These replace 
the current generic 'loader' and 'mapper' components. The generated 
loaders load the named executables and pass the data/insns to the 
generated mappers.

The generated mappers must still be connected to the appropriate 
memory/mappers/etc via hand written configury. This is just an extension 
of the current 'loader'-->'mapper' setup for single cpu simulations.

The second option is and extension of the -gdb=PORT option:

--gbdport PROCESSOR=PORT

This option generates a GDB interface component on the given port and 
interfaces it with the given processor. --gdb=PORT is equivalent to 
gdbport cpu=PORT. If both are specified and there is a conflict, the 
--gdbport option wins (with a warning).

Using these new options, and assuming that a configuration exists for a 
cpu with an additional processor 'cpu1', one could use

   <target>-sid program --gdb=1234 --load cpu1=program1 --gdbport cpu1=5678

to debug a multiple cpu simulation with 'program' being loaded into the 
main cpu and 'program1' being loaded into cpu1. One or more instance of 
GDB could be used to debug each on ports 1234 and 5678 respectively.

   <target>-sid --load cpu=program --gdbport cpu=1234 --load 
cpu1=program1 --gdbport cpu1=5678

is an equivalent command.

For all current ports, the difference in the generated config is that:

mapper  --> cpu-mapper
loader   --> cpu-loader
gdb   --> cpu-gdb
gdb-socket --> cpu-gdb-socket

All current options continue to work as expected.  Every pregenerated  
config is affected cosmetically, but not functionally. Pending approval, 
I will check in regenerated versions of each.

OK to commit?

Dave

             reply	other threads:[~2001-08-01 14:29 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-01 14:29 Dave Brolley [this message]
2001-08-02 14:50 ` Dave Brolley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3B6874C9.3030602@redhat.com \
    --to=brolley@redhat.com \
    --cc=sid@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).