Compound debug flags are intended to be a way to enable or disable a
group of simple debug flags at once, so that you don't need to enumerate
every more specialized flag in an area to get a broad amount of
debugging, nor do you give up the ability to select a general area
easily by making more specific flags.
It doesn't, however, make a lot of sense to check the value of a
compound debug flag, since it could be enabled but then have individual
subflags disabled. Exactly whether that means the compound flag should
be enabled or not is not clear, and figuring it out takes a fair amount
of work since each member simple flag needs to be visited.
Also, by having different behavior depending on the flag type, the
"enabled" method needed to be virtual.
This change eliminates the virtual method and moves the _tracing bool
member into the base class. If a subclass (only SimpleFlag currently)
wants to start or stop tracing based on itself, it should set or clear
this flag. Also, the "enabled" method has been renamed to "tracing",
since that's actually what it tracked. Being enabled by itself is not
sufficient to be tracing since there is also a global enable.
Finally, rather than duplicate the logic to convert a flag to bool in
the python wrapper, we can just use a cast to bool and take advantage of
the version in C++.
Change-Id: I3dc64c2364f0239294093686ddac6fcc8441f306
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45007
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Instead of gating the behavior of DTRACE based on TRACING_ON in the
preprocessor, move it to C++. Beyond being a little simpler, this
ensures that the value of Debug::x is always valid (the proper header is
included, x is spelled correctly, etc) even if TRACING_ON is false.
Change-Id: Ie0085c0f8753ad5283ef1850d493706b977c21a8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45006
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
The code in the body of a DPRINTF will always be compiled, even if it's
disabled. If TRACING_ON is false, the if around it will short circuit to
false without actually running any code to check the specified
condition, and the body of the if will be elided by the compiler as
unreachable code.
This creates a more consistent environment whether TRACING_ON is on or
not, so that variables which are only used in DPRINTF don't have to be
guarded by their own TRACING_ON #ifs at the call site. It also ensures
that the code inside DPRINTF is always checked to be valid code, even if
the DPRINTF itself will never go off. This helps avoid syntax errors,
etc, which aren't found because of the configuration of the build being
tested with.
Change-Id: Ia95ae229ebcd2fc9828f62e87f037f76b9279819
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44988
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
GEM5_DEPRECATED(message) expands to the [[gnu::deprecated(message)]]
attribute on gnu compatible compilers and marks an entity (function,
variable, etc) as deprecated. The msg parameter should be used to tell
the user what they should do to move away from the deprecated entity.
GEM5_DEPRECATED_MACRO(name, definition, message) is used inside an
expression-like macro with definition "definition" to mark that macro as
deprecated with message "message". For instance, if there were macros
like this:
#define SUM(a, b) ((a) + (b))
#define ONE 1
We could mark that as deprecated like so:
#define SUM(a, b) GEM5_DEPRECATED_MACRO(SUM, (a) + (b), \
"The SUM macro is deprecated, use the + operator instead.")
#define ONE GEM5_DEPRECATED_MACRO(ONE, 1, "Use the literal 1.")
Note that this macro should not be used for macros which, for instance,
declare variables, since it assumes the body of the macro expands into
an expression and not a statement or statements.
Change-Id: I58f5e834cfeeb23e37a6548433dfe7e4f695a5ec
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45086
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These would extract particular numbered source or destination registers
from an instruction and feed them into a printReg method. Now that the
register operands know how to print themselves with printReg directly,
these methods are no longer used.
Change-Id: I4244cb2ee97015f51f4783f377282e2a1db5d69b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42363
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These methods had looked up the register index using an index into the
src or dest index arrays. This level of indirection is less efficient
than using the index itself (which we know already), and also requires
that the array is layed out like how we think it is.
Before:
array idx => reg idx => folded?
After:
reg idx => folded?
Change-Id: Ice2262250ff77582ba5530fc52e6738ba1bebe18
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42356
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These were a weird holdover from when register indices were all squished
into a single scalar value, offset based on the register type. When that
change happened, the person who made it misunderstood what the
InstRegIndex type was for, and decided to build RegId into it for some
reason. The only purpose of InstRegIndex is to make sure everybody
agrees that the value being passed around is going to be used as a
register index and not a literal value, or vice versa. There is no type
associated with it as far as floating point, integer, or misc registers.
That gets applied at a different step, and actually can't be part of
InstRegIndex since the same base class may need to hold register indices
that are going to be treated as integer or floating point depending on
the subclass using them.
Also, since the values of the various constants in the DepdenceTags enum
where never actually added into register indices in the first place, the
code in the InstRegIndex constructor would never do anything. All
registers would be arbitrarily sorted into Int, FP, etc, and then when
they actually went to be used the category would be thrown away.
Change-Id: I8c4e8d6e9cdb53e298c00ad2f56e8c7304e51e96
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40339
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Rather than force all x86 microops to have one destination and two
sources, the second of which is a register or immediate, make it
possible for these microops to pick any combination of those elements by
modularizing the operand aspects of the base class. This prevents having
a bunch of extra parameters and members of the classes, or having a lot
of explicitly laid out classes with various combinations.
This also improves the accuracy/usefulness of Exec traces since register
types and therefore names will be determined correctly.
Also, there was a branchTarget override added to all register uops which
would be used when the macroop was an direct control transfer
instruction. The assumption was that the immediate value of the whole
instruction would be the PC offset, which is not necessarily correct but
is probably a fairly safe assumption.
This override was only provided for all *register* uops though, and
there's nothing saying the last uop in a branch instruction has to be a
a register uop. This change moves that override to the uop base class so
that *any* uop can be last in the macroop and still support branchTarget
correctly (or at least as correctly as a register uop would).
Change-Id: I9d42d22609d511fa757a784c04a5a9874beca479
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42343
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
It looks like this script was intended to be used to generate config.ini
files from a given gem5 configuration, although some of the functions
and paths it uses are quite obsolete and won't work any more, for
instance m5execfile and the util/pbs directory.
The currently recommended way to generate a config.ini file is to run a
configurtion up to the point it would be generated and then stop it,
that *will* work today, and while it's not necessarily elegant to have
to run a simulation to an arbitrary point and then kill it, relying on
the config.ini itself, an intermediate artifact, is also not
particularly elegant.
Rather than move this script to util or config, either of which would be
a more appropriate home for it, and then also attempting to fix it up to
work with modern gem5, where it may then still sit unused and forgotten,
it's better to just delete it and rely on the other existing method.
Change-Id: I1ae2842730bbe5e76549eb1d962d7d30fb5edfc0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45167
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This "UnitTest" would compile against and exercise the various stats
types in gem5, but did not verify that anything that happened was
correct. It was also not really a unit test in the sense that while it
did try to do something fairly specific, it did that using an
arbitrarily large portion of gem5.
Actual unit tests using the googletest framework are a more appropriate
way to test these mechanisms.
Change-Id: I3b424e9f5ffcf41f7de1cb42e6a222bf1c40054a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45166
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This "UnitTest" actually links against all of gem5, and can be used to
look at a binary and find either what symbol goes with an address, or
what address goes with a symbol.
While that could be a useful thing to want to do, there are other ways
to do that with external tools. Also, other than by seeing if this tool
compiles and manually seeing if it returns reasonable results, this
doesn't really actually test anything.
Finally, this is one of the old style "UnitTest"s, quotes intentional,
since while it may try to do a fairly specific thing, it actually
exercises an arbitrarily large portion of gem5 as a whole to do it, does
not self report success or failure, contain any test cases or input data
or expected output, and is not run automatically as part of our testing
suite.
Tests for the underlying classes in the Loader namespace would be/are
more appropriate, and make this test unnecessary.
Change-Id: I48db315d3da440fd26be0a81cc8e07affcacda46
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/45165
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This changes the base classes for load-store instructions
and introduces two new classes for DS form instructions
which use a shifted signed immediate field as the offset
from the base address and for X form instructions which
use registers for both the offset and the base address.
The formats have also been updated to make use of the new
base classes.
Change-Id: Ib5d1bb5d7747813e0e5b1e3075489f1a3aa72660
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40892
Reviewed-by: Boris Shingarov <shingarov@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
ACPI's MADT describes the interrupt system of a processor/system and
partially replaces the Intel MP tables. The config now simply adds the
ACPI variant, so an OS can use either Intel MP or ACPI for interrupt
configuration.
Change-Id: Ie3d293aac0925666f7661a03eab10218f04c8d0c
Signed-off-by: Maximilian Stein <m@steiny.biz>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42825
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
This extends the ACPI implementation to support the MADT. This table
contains information about the interrupt system (Local APIC, IO-APIC)
and partially replaces the Intel MP tables.
The change is particularly needed to support other OSes than Linux that
do not support Intel MP.
Change-Id: I132226f46f4d54e2e0b964e2986004e3e5f5f347
Signed-off-by: Maximilian Stein <m@steiny.biz>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/41953
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The RSDP points to the RSDT (32 bit) and/or the XSDT (64 bit), which are
both instances of the abstract System Description Table.
This commit implements the mechanism to write the three data structures
to memory based on the full system's configuration. The SysDescTable
class acts as base class for the RSDT and XSDT as well as any future
implementation of other System Description Tables.
Change-Id: I710279a72376c04f2a636ff2e96fa80228d03eaf
Signed-off-by: Maximilian Stein <m@steiny.biz>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/42824
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When RS and RA are both used as operands by an instruction,
RS takes precedence over RA. In such cases, either both the
register operands are used as sources or RS is a source and
RA is a destination.
This changes the order by giving RS the highest precedence
and will be useful for proper disassembly generation.
Change-Id: If351a03a814653f2f371afa936ec7a5cd4377b3a
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40890
Reviewed-by: Boris Shingarov <shingarov@gmail.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The initial device contains enough code for the gpufs configuration
scripts to register an amdgpu device that identifies as a Vega 10
(Frontier Edition) device when PCI devices are listed by Linux. It also
contains stubs necessary for adding the MMIO interface to handle driver
initialization.
Using the configuration Linux boots and the device is successfully seen
in lspci. The driver can also begin loading an successfully sends
initial MMIOs and attempts to read the ROM.
Change-Id: I7ad87026876f31f44668e700d5adb639c2c053c1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44909
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This macro is directly expecting a Debug::Flag instance as a first
argument instead of simply the name of the debug flag, and it is
forwarding it with no preprocessing to the underlying logic
(dprintf_flag).
This is different from the common DPRINTF, which is converting the
first argument into a flag and into a string literal.
This is useful if we want to pass the DebugFlag from the subclass to
the superclass. This makes it possible to set tracepoints in the
Base class logic, and let the Derived classes define the flag which
will enable the tracepoint
class Base
{
Base(const Debug::SimpleFlag &_flag)
: flag(_flag) {}
void baseLogic()
{
DPRINTFV(flag, "...");
}
const Debug::SimpleFlag flag;
}
class Derived1 : public Base
{
Derived1() : Base(Debug::Derived1) {}
}
class Derived2 : public Base
{
Derived2() : Base(Debug::Derived2) {}
}
A more concrete example is Arm Table Walker, which is using a DmaPort.
If we want to log the table walker port activity, we are using the
--debug-flags=DMA, which is unconvenient as it will contain the
logs from every DMA device in the simulation
Change-Id: I793cf1521303fd0a3bbea2059a9447386f83661e
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44967
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
This adds the definition of the Target Address Register (TAR)
and the following instructions that are associated with it.
* Move To Target Address Register (mttar)
* Move From Target Address Register (mftar)
* Branch Conditional to Branch Target Address Register (bctar[l])
Change-Id: I30f54ebd38b503fb6c9ba9dd74d00ccbbc0f8318
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40889
Reviewed-by: Boris Shingarov <shingarov@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Among the register-based conditional branch instructions,
the ones using CTR should not decrement CTR when the bit
corresponding to this action is set in the BO field of
the instruction. In this case, the instruction should be
considered invalid. This fixes the following instructions.
* Branch Conditional to Count Register (bcctr[l])
Change-Id: Ib2dbf2bc36fced580b4b7f7b76783f68361f6bbf
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/40887
Reviewed-by: Boris Shingarov <shingarov@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
checkpoint-tester script tests gem5's checkpoints by
using gem5 to produce a series of checkpoints, each with
a specified interval. After that, for all K > 1,
each of K-th produced checkpoint is used by gem5 to produce
the {K+1}-th checkpoint. The newly produced checkpoint will
be compared against the {K+1}-th checkpoint that was
previously produced.
Previously, in the tester script, the inputs to
`--take-checkpoints X,Y` was `(interval, interval)`.
The intention was to restore the N-th checkpoint and to run
the simulation for `interval` ticks.
According to the current configs/common/Options.py file,
`--take-checkpoints X,Y` means `X` is the starting tick of
the simulation, while `Y` is the number of ticks to be simulated
after tick `X`.
Therefore, `X` should be the starting tick of the N-th checkpont,
and this change addresses this problem.
Change-Id: I1fd7c91c9454f42a4fb98aa878fb5e4ac7d238f3
Signed-off-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44449
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
