linux/poky.git/meta/recipes-devtools/gcc/gcc-sanitizers.inc, branch master-next

debug_build.inc: collect debug build tuning configuration

2025-11-07T13:15:35+00:00

The modern compilers and code seem to require extra steps to avoid DEBUG errors, Move debug tuning configuration from recipes to an include file to address these errors. Drop `:remove' operation on variable, override variables directly Suggested-by: Peter Kjellerstedt (From OE-Core rev: 05c0f9caab3e76f2dfdaebba2fbd6c036f9737c5) Signed-off-by: Hongxu Jia Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie

gcc-sanitizers.inc: Workaround for aarch64

2025-01-23T11:56:47+00:00

When using the -fsanitize=address CXX_FLAG for a program compiled for aarch64 / arm64 This is happing: MemorySanitizer: CHECK failed: sanitizer_allocator_primary64.h:133 "((kSpaceBeg)) == ((address_range.Init(TotalSpaceSize, PrimaryAllocatorName, kSpaceBeg)))" (0xe00000000000, 0xfffffffffffffff4) (tid=51745) With -DSANITIZER_CAN_USE_ALLOCATOR64=0 this is not happening and potenial bugs are detected. ARM32 does not require this patch. More info about the issue in this thread: https://github.com/llvm/llvm-project/issues/65144 (From OE-Core rev: 12442b9b6df06317174066854935b1d6a4f1865d) Signed-off-by: Thomas Roos Signed-off-by: Richard Purdie Signed-off-by: Ross Burton

classes/recipes: Switch virtual/XXX-gcc to virtual/cross-cc (and c++/binutils)

2025-01-21T23:09:33+00:00

The idea of the base class dependency is to say "yes, I need a C cross compiler" and this was never meant to be gcc specific. Looking at the codebase, whilst we code triplets into this, it does overcomplicate things as there are only ever limited, "target", "sdk" and the class extended versions like mutlilib. After much thought, we can simplify this to virtual/cross-cc and virtual/nativesdk-cross-cc. This lets us remove the "gcc" specific element as well as removing the over complicated triplet usage. At the same time, change the much less widely used "g++" variant to "c++" for similar reasons and remove the triplet from virtual/XXX-binutils too. Backwards compatibility mappings could be left but are just going to confuse things in future so we'll just require users to update. This simplification, whilst disruptive for any toolchain focused layers, will make improved toolchain selection in the future much easier. Since we no longer have overlapping variables, some code for that can just be removed. The class extension code does need to start remapping some variables but not the crosssdk target recipe names. This patch is in two pieces, this one handles the renaming with the functional changes separate in a second for easier review even if this breaks bisection. (From OE-Core rev: 4ccc3bc8266c327bcc18c9a3faf7536210dfb9f0) Signed-off-by: Richard Purdie

gcc-sanitizers: Add riscv64 as compatible host

2024-12-03T11:21:34+00:00

RISC-V offers several virtual memory address schemes (Sv39, Sv48, and Sv57), but ASan currently supports only Sv39 on RISC-V64. For RISC-V64 Sv39, ASan uses custom allocator configurations tuned to manage large allocations efficiently. These tunings are incompatible with larger address spaces like Sv48/Sv57 due to differences in region sizes and alignment. For riscv64, Asan's tuning for Sv39 can be enabled in qemu by using the appropriate flag in the command line as shown below: runqemu nographic qemuparams="-cpu rv64,sv39=true" Additionally, the COMPATIBLE_HOST list in gcc-sanitizers has been updated to include riscv64. All necessary tests were successfully conducted on both hardware(Microchip PolarFire SoC) and the qemurisv64 environment, with ASan effectively detecting memory errors in both scenarios. (From OE-Core rev: 4b4450ff695ef73bf7a2437e142d2e0730d6a547) Signed-off-by: Deepthi Hemraj Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie

gcc-sanitizers: Add loongarch as a compatible architecture.

2023-09-07T06:53:51+00:00

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=600413c4f3d70392285192fb99634bcbeb97f83f (From OE-Core rev: 50649aa576b161751fd9b11ed98fe4a26b0781f8) Signed-off-by: Zang Ruochen Signed-off-by: Richard Purdie

gcc: Upgrade to GCC 13.1 release

2023-05-26T06:54:17+00:00

- Package libhwasan_preinit.o, its available on some arches e.g. x86_64 on gcc13+ - GCC 13 Porting guide [1] and major changes [2] and detailed documentation [3] - Fix aarch64 cross build when S != B [1] https://www.gnu.org/software/gcc/gcc-13/porting_to.html [2] https://www.gnu.org/software/gcc/gcc-13/changes.html [3] https://gcc.gnu.org/onlinedocs/13.1.0/ (From OE-Core rev: b80c020eaeaaae82e5b32209ca8608b36eaaee40) (From OE-Core rev: bea46612fd9106cc5b46eb1d81623b6492563c13) Signed-off-by: Khem Raj Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie

Convert to new override syntax

2021-08-02T14:44:10+00:00

This is the result of automated script conversion: scripts/contrib/convert-overrides.py converting the metadata to use ":" as the override character instead of "_". (From OE-Core rev: 42344347be29f0997cc2f7636d9603b1fe1875ae) Signed-off-by: Richard Purdie

gcc-sanitizers: Package up static hwasan files as well

2021-05-11T10:54:26+00:00

* introduced with gcc-11, other hwasan files were already packaged in: 3df4a25465 gcc-sanitizers: Package up hwasan files but static library was still triggering installed-vs-shipped (From OE-Core rev: 49aec04aa8ac98545b48c41382ebf1a1c3be1118) Signed-off-by: Martin Jansa Signed-off-by: Richard Purdie

gcc-sanitizers: Package up hwasan files

2021-03-20T18:54:56+00:00

This is introduced in GCC-11 (From OE-Core rev: 3df4a25465e488ba7c17d0b358435fc1088c6dac) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

gcc-sanitizers: Move content from gcclibdir into libdir

2021-03-02T14:15:34+00:00

In e9e5744ba8b0d43c8b874d365f83071ce20bf0a1, Khem Raj wrote: > OE does not use the traditional /usr/lib/gcc prefix to store > gcc-runtime it basically is moved into libdir, however some newer > files were installed by newer versions of gcc especially libgomp ( > omp.h openacc.h ) into gcclibdir, so we have content in both > directories, this confuses other tools which are trying to guess the > gcc installation and its runtime location, since now we have two > directories, the tools either choose one or other and we get > inconsistent behavior, e.g. clang for aarch64 uses /usr/lib but same > clang for riscv64 chose /usr/lib/gcc > This change ensures that OE ends up with single valid location for gcc > runtime files I think that the same thing needs to happen in gcc-sanitizers.inc, otherwise I get errors like: | .../recipe-sysroot/usr/include/gpg-error-64.h:884:11: fatal error: sanitizer/lsan_interface.h: No such file or directory when attempting to compile with sanitizers enabled. FILES_${PN} needs updating to match too. (From OE-Core rev: 862b4fac3ee7d951758c8c93462331ad52bf0190) Signed-off-by: Mike Crowe Cc: Khem Raj Cc: Alexandre Belloni Signed-off-by: Richard Purdie