This adds a new scons flag --no-duplicate-sources to build without
linking source files to the build directory.
I find this very helpful when using CLion, since I can now generate a
compilation database using
`bear scons build/ALL/gem5.debug --no-duplicate-sources` and CLion will
now correctly semantically analyze all the files inside src/.
It also ensures that clicking on a build warning/error now opens the
real source file rather than a symlink.
This is not enabled by default since it's possible that certain use
cases are not working correctly, but the basic testing I've done so
far appears to work just fine.
It appears that with this change the `<root>/src` directory is no longer
added to `PYTHONPATH` when running `tests/main.py`, so this change
depends on https://gem5-review.git.corp.google.com/c/public/gem5/+/68757
Change-Id: Iddc9bf9c8211e68e5432c0a07f5c95f427c1ca16
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/68518
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
The DEBUG macro is not part of any compiler standards (differently from
NDEBUG, which elides assertions).
It is only meant to differentiate gem5.debug from .fast and .opt builds.
gem5 developers have used it to insert helper code that is supposed to
aid the debugging process in case anything goes wrong.
This generic name is likely to clash with other libraries linked with
gem5. This is the case of DRAMSim as an example.
Rather than using undef tricks, we just inject a GEM5_DEBUG macro
for gem5.debug builds.
Change-Id: Ie913ca30da615bd0075277a260bbdbc397b7ec87
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69079
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
While we include shared libraries in the Executable class, we
are not doing it when linking the SharedLib. This means the
resulting Shared library won't have the library as a dependency
(it won't appear in ldd) and the symbols will remain undefined.
Any executable will fail to link with the shared library as
the executable will contain undefined references.
This bug was exposed when I tried to link util/tlm sources with
libgem5.so. As I have libpng/libpng-dev installed in my machine,
the shared library included libpng headers, but didn't link
to the library as scons didn't append "-lpng" to the linking CL.
Those png functions thus remained ubdefined symbols.
Change-Id: Id9c4a65607a7177f71659f1ac400a67edf7080fd
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/66855
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
The current protoc_action generates declarations that impose the requirement
for .proto files to import from the BUILDDIR. This prevents .proto files to
import themselves relative to their own directory.
For example, if there are two files build/pkg/a.proto and build/pkg/b.proto,
and b.proto imports a.proto, it must do so as "import pkg/a.proto", as opposed
to "import a.proto"; otherwise, the generated declaration will give rise to a
compilation error.
This is a problem for EXTRAS where .proto files are gem5-independent, so
they cannot import from gem5's build directory. An example is
https://github.com/ARM-software/ATP-Engine
This commit changes the protoc_action so that declarations are generated
relative to the SOURCE directory. This enables .proto files to import
other .proto files within the same directory.
Note it is not possible to import other .proto files in different
directories, but support for it is not currently necessary.
More details on the proto path:
https://developers.google.com/protocol-buffers/docs/reference/cpp-generated#invocation
Related:
https://gem5-review.googlesource.com/c/public/gem5/+/55903
Change-Id: Ib3e67ae817f8ad0b6803c90d23469267eff16178
Signed-off-by: Adrián Herrera Arcila <adrian.herrera@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/64491
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
This helps specify ordering for libraries that need it. Libraries with
a higher priority will be sorted earlier in the list, which can be
necessary when working with static libraries/archives.
The default value for "priority" is zero. It's only really necessary
to ensure relative ordering of particular pairings of libraries, so
it should be ok to use an absolute integer value for this. If you
need to order relative to a library, there is a good chance you're
adding it, or the place it's added is well known and you can easily
find its priority value. It's also unlikely that there would be a
complex series of interactions between libraries that would make a
more complicated system warranted.
Change-Id: Ie94a35e6563c07f8d462a4a52d0173ea3cf4f8de
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58350
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Jui-min Lee <fcrh@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
In Python, "+=" operator for list acts more like append and list assign
doesn't make a copy. This will cause unexpected append to the orignal
list. Since we have multiple env to "declare", these functions will be
called multiple times and could wrongly append duplicated entries in
later calls.
Make a copy before appending the entries from filter to avoid this
problem.
Change-Id: I144d5054e4d93191ebc94b93291ff9a3f8a6c429
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58409
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
ProtoBuf files can (and should) be declared to SCons unconditionally,
but then also use a "protobuf" tag. This lets SCons still include them
conditionally when it gathers sources to build certain binaries without
having additional python logic in SConscripts, or manually interpreting
config state.
Change-Id: I9426d647bc2d6c9d7eee7dadba77f75ed83bcaad
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58349
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
This makes what are configuration and what are internal SCons variables
explicit and separate, and makes it unnecessary to call out what
variables to export to C++.
These variables will also be plumbed into and out of kconfiglib in later
changes.
Change-Id: Iaf5e098d7404af06285c421dbdf8ef4171b3f001
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/56892
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Sometimes a library is needed to support particular functionality in
gem5, and that functionality is only used (or even desirable) in
certain binaries SCons can build. We can currently filter sources to
include in a particular executable using tags, but libraries have been
added to the environment globally using the LIBS variable which applies
to all Executables.
This change adds a SourceLib() mechanism which is a new category of
source which represents libraries. This is independent from classes
which inherit from SourceFile which represent actual files, as opposed
to more abstract libraries.
When gem5 builds an executable, the filters it provides are used to
select both Source()-es, aka c/c++ files, and libraries. If something
like a unit test does not need all the libraries gem5 proper does,
then those won't be picked up by its filter, and it won't include them.
Change-Id: I003e029eb82f7800a7ecff698c260e2d18ea2900
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58069
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
If TARGET_GPU_ISA is not set, even if the GPU ISA namespace isn't used
by anything, the logic which figures out what to set it to will fail.
This checks for that condition and sets it to something invalid, but
doesn't crash. If that namespace is actually used, then the build will
still fail.
Change-Id: Iec44255cccbafa4aceaa68bdd8b6a835dc0637a0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/56895
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Before this patch, the protobuf builder would search for dependencies
only at the build directory. This works if the importing .proto file
imports paths relative to the build directory, but it results in a build
failure if imports are done relative to the source directory of the
importing file.
This patch adds the source directory of the importing file to the set of
paths searched for dependencies, which solves this issue.
Change-Id: I7debd467485a5087276ac005ac08ab01b32cb02e
Signed-off-by: Adrián Herrera Arcila <adrian.herrera@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55963
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Before this patch, the protobuf scanner would detect implicit
dependencies only if the import statement used a path relative to the
build directory. A path with a different format would result in a build
failure.
This is inconvenient because it impedes .proto files within a source
directory to import each other relative to that source.
Moreover, this is critical for EXTRAS directories with .proto files,
because the paths are forced to include the EXTRAS directory itself.
After this patch, the protobuf scanner uses the Classic scanner from
SCons to also detect implicit dependencies in the source path of the
importing .proto file. Regex management is also delegated to the Classic
scanner.
Change-Id: I1ad466813ef44947f3da07371805cb6376e392f0
Signed-off-by: Adrián Herrera Arcila <adrian.herrera@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/55903
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This file populated the "cxx_config_directory" map from type names to
directory entry generating types. It used a comprehensive list of
includes of all SimObject headers, and a comprehensive list of the
generating types to fill everything in.
Instead, this change creates a new singleton helper class which, when
instantiated as a static member of a CxxConfigParams subclass, will
install a pointer to a CxxConfigDirectoryEntry to that map during global
object construction time.
Also, this change renames the map to cxxConfigDirectory which is in
compliance with the style guide, and puts it behind an accessor which
returns a static variable which is the actual map. This avoids any
problems that might come from global object construction order.
Change-Id: Iaa913fbe5af1b11d90ca618e29420eeb7cb0faed
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49455
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
If there really are no c++ sim_objects in the file, then sim_objects can
be set to [] which it used to default to.
This way, if someone hasn't remembered to update their SConscript files
for the new sim_objects and enums parameters, this will give them some
indication what's wrong, rather than the build just failing later.
Change-Id: Ic1933f7b9dfff7dd7e403c6c84f1f510c8ee8c72
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/54203
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Like gem5py which uses the same main source file, this program will run
arbitrary python scripts. Unlike the other program, it will include
support for the m5 module. That will make it capable of generating
SimObject param, enum, etc c++ files.
Change-Id: I15fd7545f6b1ea6559cbe27cef30c778867ebe70
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49421
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
I can't conclusively verify that this issue has been fixed because I
can't find any information about it on the internet. It's "SCons bug
2006" and "gem5 bug 308" but neither project still uses whatever bug
tracking mechanism those numbers correspond to. The change was mentioned
in the gem5 code base at least as early as 2008, and so hopefully has
been fixed in the last 13 years. I did a clean build without this
workaround, and things seem to work.
Change-Id: I155f0e72cb720fb5d35d8098375a45a69ea02263
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49419
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When calling a method in a superclass, you can/should use the super()
method to get a reference to that class. The python 2 version of that
method takes two parameters, the current class name, and the "self"
instance. The python 3 version takes no arguments. This is better for a
at least three reasons.
First, this version is less verbose because you don't have to specify
any arguments.
Second, you don't have to remember which argument goes where (I always
have to look it up), and you can't accidentally use the wrong class
name, or forget to update it if you copy code from a different class.
Third, this version will work correctly if you use a class decorator.
I don't know exactly how the mechanics of this work, but it is referred
to in a comment on this stackoverflow question:
https://stackoverflow.com/questions/681953/how-to-decorate-a-class
Change-Id: I427737c8f767e80da86cd245642e3b057121bc3b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52224
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
SCons does not use a variable called LDFLAGS, it uses one called
LINKFLAGS. Switch some errant uses to the correct name.
Also, adjust all the other variable names to use LINK, for consistency
and to avoid confusion and avoid mistakes in the future.
Change-Id: I38d40f5231afdf62bcfba04478d403d65e9b1e26
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51987
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When an object is a field in a union, it's the programmer's
resposibility to destroy it from the union's destructor. We can simply
neglect to do that and avoid having to use new to create the flags.
Also, we can define the flags as inline variables (a c++17 feature), and
then create a constexpr references to them. This lets us refer to debug
flags in constexpr objects, although we can't interact with them at, for
instance, construciton time or we'd lose our own constexpr-ness since
the actual object is not constexpr.
In c++20 we would hypothetically be able to use constexpr with new and
delete, but there may be additional restrictions that would make this
particular use impossible. Also this avoids leaking memory, which, even
though it's intentional, may confuse tools like valgrind.
Also, we need to ensure that all headers are included in some source
file so that they exist in the final executable, so that they show up in
the help, can be enabled/disabled, etc.
Change-Id: Ia43111d938e7af7140b1c17dd68135f426d0a1e9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49783
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Jui-min Lee <fcrh@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The code which generated SimObject related param wrappers, cxx wrappers,
enum headers, etc was organized strangely. All the functions which
were used as SCons Actions were listed next to each other, and then all
the code which would set up each of those types of files and actually
use the Actions were next to each other.
This change rearranges that code so that the Action function is
immediately before the code which applies it. Or in other words, this
section of the SConscript is now grouped by the files being created,
rather than the type of the piece of machinery being defined to do that.
Change-Id: Ideee7bd44dac89c51840ec5970d95f6ccbbd1c8f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49402
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
The Executable class was used both for the generic gem5 target, and as a
base for the GTest binaries, the systemc test binaries, etc.
Unfortunately, the gem5 binary needs to include src/base/date.cc, and to
ensure that that file is up to date, it needs to depend on all the other
object files. No other binary should have that, but it was included by
inheritance.
Also, depending on the object file works well when those object files
and the date.cc object file are all part of the same binary and not
mixed and matched. That is not true for the GTest binaries for instance,
and so building a unit test would also build all the other unit test
object files because they are dependencies for date.to, date.tdo, etc.
If they already exist, then they would satisfy the dependency and not be
rebuilt.
Change-Id: Ia9cdddc5b2593678e714c08655eb440d7f5b5d1f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51088
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
