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
next 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).