gem5/src/mem/ruby at b9bc530ad20bceeed6e43ea459d271046f43e70c - sanchayanmaity/gem5

History

Andreas Hansson b6aa6d55eb clang/gcc: Fix compilation issues with clang 3.0 and gcc 4.6 This patch addresses a number of minor issues that cause problems when compiling with clang >= 3.0 and gcc >= 4.6. Most importantly, it avoids using the deprecated ext/hash_map and instead uses unordered_map (and similarly so for the hash_set). To make use of the new STL containers, g++ and clang has to be invoked with "-std=c++0x", and this is now added for all gcc versions >= 4.6, and for clang >= 3.0. For gcc >= 4.3 and <= 4.5 and clang <= 3.0 we use the tr1 unordered_map to avoid the deprecation warning. The addition of c++0x in turn causes a few problems, as the compiler is more stringent and adds a number of new warnings. Below, the most important issues are enumerated: 1) the use of namespaces is more strict, e.g. for isnan, and all headers opening the entire namespace std are now fixed. 2) another other issue caused by the more stringent compiler is the narrowing of the embedded python, which used to be a char array, and is now unsigned char since there were values larger than 128. 3) a particularly odd issue that arose with the new c++0x behaviour is found in range.hh, where the operator< causes gcc to complain about the template type parsing (the "<" is interpreted as the beginning of a template argument), and the problem seems to be related to the begin/end members introduced for the range-type iteration, which is a new feature in c++11. As a minor update, this patch also fixes the build flags for the clang debug target that used to be shared with gcc and incorrectly use "-ggdb".		2012-04-14 05:43:31 -04:00
..
buffers	Ruby: Ensure order-dependent iteration uses an ordered map	2012-04-12 08:35:49 -04:00
common	clang/gcc: Fix compilation issues with clang 3.0 and gcc 4.6	2012-04-14 05:43:31 -04:00
eventqueue	Ruby EventQueue: Remove unused functions	2012-01-11 13:31:04 -06:00
filters	BuildEnv: Eliminate RUBY as build environment variable	2011-08-08 10:50:13 -05:00
network	clang/gcc: Fix compilation issues with clang 3.0 and gcc 4.6	2012-04-14 05:43:31 -04:00
profiler	clang/gcc: Fix compilation issues with clang 3.0 and gcc 4.6	2012-04-14 05:43:31 -04:00
recorder	mem: Add a master ID to each request object.	2012-02-12 16:07:38 -06:00
slicc_interface	Ruby: Add infrastructure for recording cache contents	2012-01-11 13:29:15 -06:00
system	clang/gcc: Fix compilation issues with clang 3.0 and gcc 4.6	2012-04-14 05:43:31 -04:00
Decomissioning_note	ruby: Import ruby and slicc from GEMS	2009-05-11 10:38:43 -07:00
README.debugging	ruby: Import ruby and slicc from GEMS	2009-05-11 10:38:43 -07:00
SConscript	Ruby: Remove some unused typedefs	2011-11-03 22:46:45 -05:00
SConsopts	Gems: Eliminate the now unused GEMS_ROOT scons variable.	2011-03-11 11:27:26 -08:00

README.debugging

# ------ Debugging the Ruby Tester ------

You can compile Ruby with debugging turned on.

cd ruby
[vim or emacs] Makefile

Change OPT_FLAGS to "-g -O0" (the first OPT_FLAGS line). Make
sure all the other OPT_FLAGS lines are commented out.

Change DEBUG_FLAGS to "-DRUBY_DEBUG=true". (Just uncomment the
first DEBUG_FLAGS line, and comment out the second DEBUG_FLAGS
line.)

You can choose which component or components to debug, and the
level of verbosity. For example,

"x86-linux/generated/MOSI_SMP_bcast/bin/tester.exec -l 100000 -v med -c n"

gives you debugging information about the network component at
the medium verbosity level. -v selects the verbosity, which may
be low, med, high, or none. -c selects the component or
components.

"x86-linux/generated/MOSI_SMP_bcast/bin/tester.exec -l 100000 -v med -c nSt"

debugs the network, the sequencer, and the tester.

For a list of the components you can debug, just run the tester with
no arguments, and it will display a list of valid components. The
components are defined in ruby/common/Debug.def.

The protocol debug trace is especially useful for debugging cache coherence protocols. This must be enabled at compile-time by ensuring that PROTOCOL_DEBUG_TRACE is set to true for rubyconfig.defaults (if running in Simics) or tester.defaults. You must specify the time to start tracing. The following starts the protocol trace immediately (at time 1)

"x86-linux/generated/MOSI_SMP_bcast/bin/tester.exec -l 100000 -s 1"

Also, if something seems to be wrong and you're not sure where to
start looking, it may help to run the tester for a longer time,
e.g.

"x86-linux/generated/MOSI_SMP_bcast/bin/tester.exec -l 500000"

This may help because some problems eventually show up as
deadlock, but the tester has to run for a long time before a
deadlock is detected.

Once your simulator has succeeded on the tester for a certain
number of cycles, say 1000000, you may want to set the
RANDOMIZATION variable in ruby/config/tester.defaults to "true"
for more thorough testing. However, RANDOMIZATION may not work in
all situations because it overrides some of the ordering in the
network and may break your simulator in ways you don't like. For
example, messages are added to MessageBuffers with random
latency.

By default the tester driver is a generator that issues random store
and load requests. This driver does a good job of stressing the
cache coherency protocol by issuing racy store requests from multiple
processors to a cache line then checks the stores with a single load.

Other tester drivers are available. By setting the g_SYNTHETIC_DRIVER
to true in ruby/config/tester.defaults, you enable a tester that generates
racy lock requests for a number of locks indicated by g_synthetic_locks.

Another tester driver is a series of non-racy deterministic testers. By
setting the g_DETERMINISTIC_DRIVER in ruby/config/tester.defaults to true,
you enable the deterministic tester. The deterministic tester can do
different types of deterministic tests as specified by g_SpecifiedGenerator
string. The deterministic tester works best when RANDOMIZATION is set to
false. To easily track the queues being used with the deterministic tester,
use the following debug flags "-v low -c nq".

# ------ Debugging Ruby in Simics ------

When you're running Simics, the debugging components and
verbosity levels are the same. However, the way you communicate
with Ruby changes.

See the README.quickstart for information on compiling the Ruby
module and loading it into Simics. Once you've got Simics
running, with the Ruby module loaded, you can set up Ruby
debugging.

To set the debugging verbosity level, run:

simics> ruby0.debug-verb med

To set the debugging components, run: (see common/Debug.def for complete list
of component shortcuts)

simics> ruby0.debug-filter n

(NOTE: sometimes simics will interpret a single letter as a
command; e.g. expanding "p" into "print". If simics gives you an
error when setting the debug filter, try setting it like so:
simics> ruby0.debug-filter "n")

This gives the same kind of debugging information as running the
tester with "-v med -c n".

You can also send the debugging output to a file (may be a good
idea, since there's a lot of it). To do this, run:

simics> ruby0.debug-output-file <filename>