When running `scons build/ALL/gem5.opt --with-ubsan`, with GCC, the
following error was returned:
```
[ CXX] src/base/loader/image_file_data.cc -> ALL/base/loader/image_file_data.o
In file included from /usr/include/string.h:535,
from /usr/include/c++/11/cstring:42,
from src/base/cprintf_formats.hh:33,
from src/base/cprintf.hh:38,
from src/base/logging.hh:49,
from src/base/loader/image_file_data.cc:40:
In function ‘char* strcpy(char*, const char*)’,
inlined from ‘int gem5::loader::doGzipLoad(int)’ at src/base/loader/image_file_data.cc:70:11,
inlined from ‘gem5::loader::ImageFileData::ImageFileData(const string&)’ atsrc/base/loader/image_file_data.cc:116:24:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:79:33: error: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’ offset [0, 19] is out of the bounds [0, 0] [-Werror=array-bounds]
79 | return __builtin___strcpy_chk (__dest, __src, __glibc_objsize (__dest));
| ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1plus: all warnings being treated as errors
scons: *** [build/ALL/base/loader/image_file_data.o] Error 1
scons: building terminated because of errors.
```
I do not know the exact issue but using strcpy in this way (i.e.
`strcpy(char_pointer + offset, string)`) appears to trigger this error
with the undefined behavior sanitizer. The fix in this patch replaces
this with `strcat`.
Change-Id: I1a0c50c9022adc841e175aad0fe2247bfcb29d71
An issue raised in #240 where if an address range ends
at the last byte of a 64 bit address space, it will be
considered a subset of any other address range that starts
at the first byte of the range.
Change-Id: I517f4717052eda2504de971be0eb59ee9a623dd3
Add a size field to the Symbol objects in the Symbol Table. This
allows client code to read the data associated with a symbol in cases
where the data type/size is not known beforehand (e.g. if an object's
size might be different between different versions of a
workload/kernel).
Access is mediated via the `sizeOrDefault()` method, which requires
client code to specify a fallback size. Since correct size data may
not be available (for example in legacy checkpoints), this forces the
client code to consider the 'missing size data' case.
Change-Id: If1a47463790b25beadf94f84382e3b7392ab2f04
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
This commit converts `gem5::loader::Symbol` to a full class with
private members, enforcing encapsulation. Until now client code has
been able to (and does) access members directly.
This change will enable class invariants to be enforced via accessor
methods.
Change-Id: Ia0b5b080d4f656637a211808e13dce1ddca74541
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
These are not yet consumed by anything, but convert all the settings
from SCons variables to Kconfig variables.
If you have existing SConsopts files which need to be converted, you
should take a look at KCONFIG.md to learn about how kconfig is used in
gem5. You should decide if any variables need to be available to C++ or
kconfig itself, and whether those are options which should be detected
automatically, or should be up to the user. Options which should be
measured automatically should still be in SConsopts files, while user
facing options should be added to new or existing Kconfig files.
Generally, make sure you're storing c++/kconfig visible options in
env['CONF'][...]. Also remove references to sticky_vars since persistent
options should now be handled with kconfig, and export_vars since
everything in env['CONF'] is now exported automatically.
Switch SCons/gem5 to use Kconfig for configuration, except EXTRAS which
is still a sticky SCons variable. This is necessary because EXTRAS also
controls what config options exist. If it came from Kconfig itself, then
there would be a circular dependency. This dependency could
theoretically be handled by reparsing the Kconfig when EXTRAS
directories were added or removed, but that would be complicated, and
isn't supported by kconfiglib. It wouldn't be worth the significant
effort it would take to add it, just to use Kconfig more purely.
Change-Id: I29ab1940b2d7b0e6635a490452d05befe5b4a2c9
Symbol type is part of the info provided by an ELF object's symtab.
It indicates whether a symbol is a file symbol, or a function symbol, etc.
Change-Id: I827e79f8439c47ac9e889734aaf354c653aff530
Signed-off-by: Hoa Nguyen <hn@hnpl.org>
Currently the type of HAVE_DEPRECATED_NAMESPACE is used to detect
if the compiler support gnu::deprecated feature. The return type
of conf.TryCompile is int, but HAVE_DEPRECATED_NAMESPACE is used
as boolean type. The CL is add bool type caster to ensure the type
of it is boolean.
Change-Id: Ife7d9716e485a8be8722d58776f064e7c2268a30
Current we drop the insertion of a whole symbol table if the name
of one symbol already exists in the base table. Having similar
symbols across different binaries is very common.
This change adds a warning and recommends a fix instead of silently
dropping the table. This is useful for debugging when there are two
or more workloads, e.g. bootloader + kernel, are added separately.
Change-Id: I9e4cf06037cd70926fb5cee3c4dab464daf0912e
Signed-off-by: Hoa Nguyen <hn@hnpl.org>
Compilation bug found on:
https://github.com/gem5/gem5/actions/runs/5899831222/job/16002984553
In gcc Version 8 and below the following error is received:
```
src/base/bitfield.hh: In function ‘constexpr int gem5::findLsbSet(uint64_t)’:
src/base/bitfield.hh:365:34: error: call to non-‘constexpr’ function ‘int gem5::{anonymous}::findLsbSetFallback(uint64_t)’
return findLsbSetFallback(val);
~~~~~~~~~~~~~~~~~~^~~~~
scons: *** [build/ALL/kern/linux/events.o] Error 1
```
`findLsbSet` cannot be `constexr` as it calls non-constexpr function
`findLsbSetFallback`. `findLsbSetFallback`. The problematic function is
the `count` on the std::bitset.
This patch changes this to a constexpr.
Change-Id: I48bd15d03e4615148be6c4d926a3c9c2f777dc3c
* base: Enable stl_helpers::operator<< in _formatString
The string format (%s) eventually relies on bare operator<< to
display any type T. This gives the opportunity to use the helpers in
stl_helpers. This patch enables printing enums, pairs, tuples,
vectors, maps and others in a PRINTF debug macro without any extra
manual operation.
Change-Id: I8ac85133ebadcb95354598c1cfe687d8fffb89e2
* base: Add Printer util class to force use of operator<< helpers
Wrapping any value in a Printer instance before using operator<< will
force the use of stl_helpers::operator<<.
Change-Id: I7b505194eeabc3e0721effd9b5ce98f9e151b807
* base: Fix typo in ostream_helpers.hh
Change-Id: I283a5414f3add4f18649b77153dcbcc8661bc81e
* base: Disambiguate null optional representation in ostream helper
Change-Id: I5b093555688566cc405248d3a448a8f3efa67888
* base: Add unit test for std::optional ostream helper
Change-Id: I6fb9ced5e6461de5685638a162b5534e10710e20
* base: Ostream helpers Printer unit test
Change-Id: I11db89e85fd40c12bceecb41cadee78b8e871d7b
* base: Unit test for ostream helpers for pointers and smart ptr
Change-Id: Ifa87e8b69fdd9a4869250ab40311f352e8f54ed9
* base: Coding style fix in ostream_helpers.test.cc
Change-Id: I095c7048fad35e63f979aa601bfc8cde65c9077b
* base: Test shared_ptr in ostream_helpers.test.cc
Change-Id: I553df0614f1dd6eef2061c4dc1794af8c543b78f
---------
Co-authored-by: Gabriel Busnot <gabriel.busnot@arteris.com>
When compiling with clang-14 I received the following error:
```
src/base/bitfield.hh:328:1: error: function 'findLsbSetFallback' is not needed and will not be emitted [-Werror,-Wunneeded-internal-declaration]
```
This function was introduced in PR #76.
This fixes this compiler warning/error by using `[[maybe_unused]]`.
Change-Id: I0b99eab0a9e42ee1687e7a0594a5a7bf9588b422
* base: Fix Memoizer constructor parameter type
* base: switch from new to mk_unq in amo.test.cc
* base: Fix memory management in IniFile
* base: Fix memory management in Trie
* sim: Fix out-of-bounds access in CheckpointIn::setDir
Change-Id: Iac50bbf01b6d7acc458c786da8ac371582a4ce09
---------
Co-authored-by: Gabriel Busnot <gabriel.busnot@arteris.com>
Added dummy definition of __has_builtin to bitfield.hh's hasBuiltinCtz,
which is already being done in popCount.
Change-Id: I4a1760a142209462bb807c6df4bc868284b6f5f3
* base: Generalize findLsbSet to std::bitset<N>
* base: Split builtin and fallback implementations of findLsbSet
* base: Add more unit testing for findLsbSet
Change-Id: Id75dfb7d306c9a8228fa893798b1b867137465a9
---------
Co-authored-by: Gabriel Busnot <gabriel.busnot@arteris.com>
This operator can be safely brought in scope when needed with "using
stl_helpers::operator<<".
In order to provide a specialization for operator<< with
stl_helpers-enabled types without loosing the hability to use it with
other types, a dual-dispatch mechanism is used. The only entry point
in the system is through a primary dispatch function that won't
resolve for non-helped types. Then, recursive calls go through the
secondary dispatch interface that sort between helped and non-helped
types. Helped typed will enter the system back through the primary
dispatch interface while other types will look for operator<< through
regular lookup, especially ADL.
Change-Id: I1609dd6e85e25764f393458d736ec228e025da32
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/67666
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
These types include std::pair, std::tuple, all iterable types and any
composition of these. Convenience hash factory and computation
functions are also provided.
These functions are in the stl_helpers namespace and must not move to
::std which could cause undefined behaviour. This is because
specialization of std templates for std or native types (or
composition of these) is undefined behaviour. This inconvenience can't
be circumvented for generic code. Users are free to bring these hash
implementations to namespace std after specialization for their own
non-std and non-native types.
Change-Id: Ifd0f0b64e5421d5d44890eb25428cc9c53484eb3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/67663
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Daniel Carvalho <odanrc@yahoo.com.br>
Tested-by: kokoro <noreply+kokoro@google.com>
This change addresses an error in the compiler tests:
https://jenkins.gem5.org/job/compiler-checks/573/
For clang versions 6 through 10, as well as GCC 7,
in order to use the "filesystem" module, you must
include the experimental namespace. In all newer
versions, you can use the "filesystem" module as is.
Because of this, include guards to handle this. They include
"<experimental/filesystem>" for the older clang versions and
the "<filesystem>" for all other versions.
As opposed to checking by version, we now check if the
filesystem library has been defined before using it.
Change-Id: I8fb8d4eaa33f3edc29b7626f44b82ee66ffe72be
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69778
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Normally this would just generate a warning, but a warning is easy to
miss, and truncating the path to fit would be surprising. Since the max
length isn't likely to change, a path which has to be truncated is
essentially fundementally wrong, and could be defined as something
else which is short enough before being used in the config.
Note that this only applies to either the abstract path which is just
a string, or the file name and not the directory path on a file based
socket.
Change-Id: I8702cf02c03053b5d0b6133f25b0e588de666f15
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69677
Maintainer: Gabe Black <gabeblack@google.com>
Reviewed-by: Earl Ou <shunhsingou@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These can either be set to an integer, in which case it's interpreted
as a TCP port, or a string, in which case it's treated as a unix domain
socket. If the unix domain socket is prefixed with a "@", it will be
treated as an abstract socket.
When stored in the ini file, there is always a prefix added to make
parsing the string more systematic and less ambiguous. A port number is
prefixed with "#", an abstract socket with "@", and a socket file with
the prefix "P" for "path".
Change-Id: I1fc7a579074e849b3becd936238c62fb0d9a2087
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69165
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
gem5 officially supports GCC 7+. In GCC 7 the "filesystem" module was
added but only in the "experimental" namespace as
"<experimental/filesystem>". In GCC 8+ the module can be found as
"<filesystem>".
Because of this, include guards to handle this. They include
"<experimental/filesystem>" for the GCC v7 case and the "<filesystem>"
for all other versions.
This bug was partially responsible for this compiler tests failures:
https://jenkins.gem5.org/job/compiler-checks/570
Note: gem5 does not support GCC versions <7. Thus the
"#if __GNUC__ >=8 <GCC 8+ code> #else <GCC 7 code> #endif" logic is
valid.
Change-Id: I31db5488f272f9652edebf24ecefca3722369076
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69598
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Create a version of listen() which handles common logic internally,
including scanning for an available port number, and notifying what
port was chosen.
The port is managed internal to ListenSocket, so that the logic
interacting with it doesn't need to manually manage a port number, and
hence a port number does not need to exist for non AF_INET sockets.
Change-Id: Ie371eccc4d0da5e7b90714508e4cb72fb0091875
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69160
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
