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 <Deepthi.Hemraj@windriver.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As commit 81551871b183 (gcc: Remove Java support variables) correctly
stated
Java support was removed in upstream gcc 7.
but this line snuck back in with commit bbf32e24608c (gcc-9: Add
recipes for gcc 9.1 release).
(From OE-Core rev: 136619477f0ce7c9da0762bbbeb1227a1ad6c0c7)
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is an issue in the std::chrono::tzdb parser that causes problems
since the tzdata-2024b release started using %z in the main format.
As a real world problem I encounter an issue with the waybar clock module,
which ignores the timezone setting and only shows system time.
(From OE-Core rev: 39018429f05511053ab12e23e7f4487ea25ee529)
Signed-off-by: Markus Volk <f_l_k@t-online.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The '-fdebug-prefix-map' options are used to map source files locations,
otherwise, DW_AT_comp_dir will contain buildpath.
The '-gno-record-gcc-switches' option is used to fix the buildpath introduced
by '-fintrinsic-modules-path' option, which is automatically added by fortran.
Here's some output from 'readelf --debug-dump libgfortran.so.5.0.0' when this
option is not added:
"""
<0><1a37d3>: Abbrev Number: 4 (DW_TAG_compile_unit)
<1a37d4> DW_AT_producer : (indirect string, offset: 0xd653): GNU Fortran2008 14.2.0 -m64
-march=core2 -mtune=core2 -msse3
-mfpmath=sse -mshstk -g -O2 -O2 -fstack-protector-strong -fimplicit-none
-fno-repack-arrays -fno-underscoring -fcf-protection=full
-fallow-leading-underscore -fbuilding-libgfortran -fPIC
-fintrinsic-modules-path /ala-lpggp72/qichen/Yocto/builds/build-poky/tmp/work/
core2-64-poky-linux/libgfortran/14.2.0/recipe-sysroot-native/usr/bin/x86_64-poky-linux
/../../lib/x86_64-poky-linux/gcc/x86_64-poky-linux/14.2.0/finclude
-fpre-include=../../../../recipe-sysroot/usr/include/finclude/math-vector-fortran.h
"""
See https://gcc.gnu.org/pipermail/fortran/2024-October/061204.html for more
detailed information.
(From OE-Core rev: 1eb084956bcba83782bc2b24cf8cc89459a57e34)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
While enabling multilib, build gcc-source-14.2.0 and lib32-gcc-source-14.2.0
at the same time:
$ MACHINE = "qemux86-64"
$ require conf/multilib.conf
$ MULTILIBS = "multilib:lib32"
$ DEFAULTTUNE:virtclass-multilib-lib32 = "x86"
$ bitbake gcc-source-14.2.0 lib32-gcc-source-14.2.0
...
$ cat tmp-glibc/work-shared/gcc-14.2.0-r0.vr2401/temp/log.task_order
20241012-064533.415426 do_recipe_qa (2688052): log.do_recipe_qa.2688052
20241012-064533.463783 do_recipe_qa (2688051): log.do_recipe_qa.2688051
20241012-064533.805164 do_fetch (2688257): log.do_fetch.2688257
20241012-064533.852955 do_fetch (2688256): log.do_fetch.2688256
20241012-064617.823714 do_unpack (2698542): log.do_unpack.2698542
20241012-064617.871730 do_unpack (2698541): log.do_unpack.2698541
...
There are two tasks for do_fetch, do_unpack and others, so there are race issues.
Both of them have the same hardcode 'gcc' prefix in ${WORKDIR} and
${S}, explicitly disable lib32-gcc-source-14.2.0 for multilib
Set gcc-source as BPN of gcc-source-14.2.0
(From OE-Core rev: 901c47877e0710af50639f688e0bfdb851b762b5)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
while runnig oe-selftest for gcc, testcases that need to be run on qemu are not running due to below failures.
- Executing on ssh: mkdir -p /tmp/runtest.3549641 (timeout = 300)
spawn [open ...]
Host key verification failed.
ERROR: Couldn't create remote directory /tmp/runtest.3549641 on ssh
Host key verification failure is happening when ssh board config file name is
defined as "ssh.exp" and there are multiple ssh.exp files generated during the build
and a wrong ssh config was taken. To resolve this changed the board config file name
to "linux-ssh.exp" which ensures correct ssh settings are used.
(From OE-Core rev: d32ec0b4d242879ab8eaf96e1cb407e8f0bb9f3d)
Signed-off-by: Harish Sadineni <Harish.Sadineni@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adding a "network" task specific flag which then triggers networking to
be enabled for this task, it is otherwise disabled which will cause
failures while running oe-selftest.
Fixes the following issues while running oe-selftest for gcc:
1)ssh: connect to host X.X.X.X port 22: Network is unreachable.
2)Bad owner or permissions on /etc/ssh/ssh_config.d/50-redhat.conf.
(From OE-Core rev: 35782416823fa863d26a338256f642f6bc480a96)
Signed-off-by: Harish Sadineni <Harish.Sadineni@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since target and cross variants were already doing similar cleanup
of include-fixed headers, as those aren't used, unify the code and
also apply the same to cross-canadian variant.
Some of those header files get processed with a tool that leaves
absolute buildpaths inside the file's commented section, causing
QA errors. Since those aren't used, let's remove them.
This may be a temporary solution until the tool itself gets fixed
to not embed absolute buildpaths in the header files:
https://lists.openembedded.org/g/openembedded-core/topic/107268307
(From OE-Core rev: 9221e4ab8cca4c06dc3d5c1de2fd4ce46477578a)
Signed-off-by: Denys Dmytriyenko <denys@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Apply fixes from gcc-cross (84a78f46d594 and 0ead8cbdfb96) to gcc-cross-canadian.
This will improve (but not fix) reproducibility of gcc-cross-canadian.
Also move this code to functions to avoid code duplication.
[RP: Tweak patch to make the function parameters clear and fix quoting issues
ensuring the code exactly matches the original replacements with an additional
parameter.]
(From OE-Core rev: 350ff7d53f7506de2bc01f0efc569b8294b9afea)
Signed-off-by: Oleksandr Hnatiuk <ohnatiuk@cisco.com>
Signed-off-by: Denys Dmytriyenko <denys@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Enables usage of TCLIBC=picolibc extending OE functionality to build and use
picolibc based toolchains to build baremetal applications.
Picolibc is a set of standard C libraries, both libc and libm, designed for
smaller embedded systems with limited ROM and RAM. Picolibc includes code
from Newlib and AVR Libc, but adresses some of newlibs concerns, it retains
newlibs directory structure, math, string and locale implementations, but
removed the GPL bits used to build the library, swiches old C style code for
C18 and replaces autotools with meson.
This patch adds a picolibc recipe for the C library, a picolibc-helloworld
recipe that contains an example application and a testcase that builds it.
Picolibc can be built for ARM and RISCV architectures, its been tested both
for 32 and 64 bits, the provided example recipe produces the following output:
hello, world
Runqemu does not automatically show any output since it hides QEMU stderr which
is where the QEMU monitors output is directed to when using semihosting, but,
manually running the same QEMU command does work properly.
(From OE-Core rev: c7535ecaccb72ef21a61f9aec5c68e61fb4f6fb6)
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandro@enedino.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It fails to run both `gcc` and `gfortran` with errors:
| root@qemux86-64:~# x86_64-poky-linux-gcc a.c
| x86_64-poky-linux-gcc: fatal error: cannot execute 'as': posix_spawnp: No such file or directory
then add binutils which provides `as` to RDEPENDS of gcc.
libgfortran-dev provides libgfortran.spec which required by gfortran:
| root@qemux86-64:~# gfortran hello.f95
| gfortran: fatal error: cannot read spec file 'libgfortran.spec': No such file or directory
And gcc provides liblto_plugin.so:
| root@qemux86-64:~# gfortran hello.f95
| gfortran: fatal error: '-fuse-linker-plugin', but liblto_plugin.so not found
(From OE-Core rev: 44fc7aa1468ff042739cc5a91c84ef5c2a09e0a3)
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
g77/f77 has been removed from gcc 4.0.0 via commit:
* b4117c30610 Makefile.def, [...]: Remove all mention of libf2c.
When set
FORTRAN = ",f77"
it complains with error:
| The following requested languages could not be built: f77
| Supported languages are: c,c,c++,fortran,go,lto,m2,objc,obj-c++
So remove g77/f77 from gcc recipes.
[1]: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b4117c30610
(From OE-Core rev: 6469c6a00066af24c87ec5dd7994ebbc610c3782)
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With the addition of the C++ runtime setting added recently, allow
gcc to use libc++ as its runtime. There's some minor fixes still
required, such as allowing setting the unwinder library. But this
allows for testing libc++ with gcc.
(From OE-Core rev: f84ae97e2bc081c972e78ee4a958f21111dbbfb6)
Signed-off-by: Daniel McGregor <daniel.mcgregor@vecima.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
ERROR: gcc-runtime-14.1.0-r0 do_package: QA Issue: gcc-runtime: Files/directories were installed but not shipped in any package:
/usr/share/info
/usr/share/info/libgomp.info-2
/usr/share/info/libgomp.info-1
(From OE-Core rev: 4f73ddd6c276dcd579d2113db1974d446dbf7751)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
gcc testsuite unable to read the value of variable $do-what-limit and causing below tcl errors.
ERROR: can't read "do": no such variable
while executing
"set do_what $do-what-limit"
To fix this, quote the variable using braces, as in ${do-what-limit}.
(From OE-Core rev: e59421468d96282057f5176438a76a325b987e47)
Signed-off-by: Harish Sadineni <Harish.Sadineni@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When debugging a C++ program on target using libcstdc++, gdb does not
find the pretty printer python support, this is because the init file is
installed into /usr/lib which is excluded from gdb's default list of
directories to load config's from, where as defaults to load from
datadir is still on, it therefore does not load this file
warning: File "/usr/lib/libstdc++.so.6.0.33-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
This leaves the libstdc++ pretty-printers disabled even though added via
IMAGE_INSTALL += "gcc-runtime-dbg"
Comment on adding missing runtime dependency on datetime python module for the pretty
printer to work/load successfully.
Once the pretty-printer gdb file is moved out of libdir, it may become
empty therefore delete it if its empty.
(From OE-Core rev: d24e16d192f21aa68b5274496efaba1d913f37c2)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is fixed via a patch added in gcc-13.2.inc already, but still
reported e.g. for libgcc as it is not defining an own source but use the
shared gcc-source.
(From OE-Core rev: 301d45eacfd4ae6bddfb13207e2af9e8b4662bc8)
Signed-off-by: Simone Weiß <simone.p.weiss@posteo.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Debian 12 no longer supports replacing dash with bash as default shell.
Therefore to achieve compatibility with Debian 12, all bashisms need
to be removed.
Shell comparison via == gives an error with dash and thus the condition
is always false.
(From OE-Core rev: 3723b26f82219ff71823335d550dbf29086d63d4)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Disable loongson-mmi runtine, qemu doesn't appear to fully support them even if some
of the instruction decoding is there.
Also disable MSA mips runtime extensions. For some reason qemu appears to accept the test
code when it shouldn't. Our selected MIPS cpu for QEMU doesn't support them.
MIPS is unusual in the gcc testsuite as it uses EFFECTIVE_TARGETS and loops
multiple times through the vector testsuite. In the case of the two above, we can
compile/link them but not run them. Even with the runtime disabled, if the code
marks it as a runtime test, it will elevate itself to that. Setting the default
target to compile therefore isn't enough.
Therefore add code to downgrade runtime tests to link tests if the hardware
support isn't there to run them. This avoids thousands of test failures. To do
this we have to hook downgrade code into the main test runner.
Enable that downgrading for other cases where hardware to run vector extensions is
unavailable to remove test failures on other architectures too.
Also, for gcc.target tests, add checks on wheter loongson or msa code can
be run before trying that, allowing downgrading of tests there to work too.
Parts of the patch may be able to be split off and acceptable to upstream with
discussion. Need to investigate why qemu-user passes the 'bad' instructions'.
For now, this should at least remove hundreds of test failures and improve test
failures on non-mips too now a root cause of some was identified.
(From OE-Core rev: bdb744edfec77d3fb000da0fe432689089b20d02)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
MIPS sets QEMU CPU values similarly to ppc and doens't support 'max'.
Allow this to filter through correctly to the toolchain testing.
(From OE-Core rev: 8c939780228d1440190a87cc24abd72d26aade74)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This code doesn't do what it first might appear to, it would for example remove
'm' characters from the left side of qemu-mips leaving 'ips'. Fix it to stop
anyone else being confused by the subtle logic error.
(From OE-Core rev: 888a7edf1c611eaf99eaf10a072ecc82cb386735)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The gcc_multilib_setup function is a function that is run at the
do_configure step, so it's counted into the signature computation.
The MULTILIB_VARIANTS this function uses is also extracted to be
taken into consideration. After the change of setting MULTILIB_VARIANTS
explictly vardeps on MULTILIBS, the change of MULTILIBS changes the
signature, thus causing rebuilding. However, in case of gcc-crosssdk,
the setting of multilib should have no effect on it, as it's used
to build nativesdk packages, not the target packages. So ignore
MULTILIB_VARIANTS in signature computation. This fixes oe-selftest
case sstatetests.SStateHashSameSigs2.test_sstate_nativesdk_samesigs_multilib.
(From OE-Core rev: 537c71162a711dec32a63a657c4b101269a3e267)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After this change in qemu:
c7e89de132
there is no 'max' cpu model on ppc. Drop it to clean up ppc gcc testsuite failures.
In order for this to work we do need to pull in the alternative cpu option from
QEMU_EXTRAOPTIONS on powerpc.
(From OE-Core rev: c447f2b21b20fb2b1829d540af2cc0bf8242700c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
By changing the default code generation of GCC we're inadvertently
breaking the GCC test suite, which has ~120K+ more failures when run for
aarch64 compared to x86-64.
This was because the generated code fragments included the BTI
instructions, which the test case wasn't expecting. We can't tell the
tests globally to run without branch protection, as that will break the
tests which also turn it on.
Remove the enabling of branch protection by standard in GCC, we'll
enable it in the tune files instead.
(From OE-Core rev: bb4b9017db6a893ed054a2d2ad4cc671dec09c42)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
libgcc is linked with GNU BFD linker make sure it does not assume
default ld to be BFD linker rather demand it explicitly
(From OE-Core rev: 856b4ec58fd5391069eaf43ab1b7426d49d9b7de)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some distros e.g. gentoo have latest on gcc-13 branch and we have a
situation where libstdc++ ABI is changed between 13.1 and 13.2 so
official 13.1 release based uninative will no longer work on these
distros, therefore switch to a snapshot that includes [1] which fixes
it
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
Reported-by: Martin Jansa <Martin.Jansa@gmail.com>
(From OE-Core rev: d554c404166f6ba1aa247c377fa9d3316e53aa40)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Cc: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is little point in having "crosssdk" suffex added to the virtual provider within
gcc/go since the TARGET_PREFIX or SDK_PREFIX already encapsulates this. Remove it
allowing some of the special case overriding to be removed.
This also allows removal of some of the MLPREFIX usage since again, the triplet
also covers this.
(From OE-Core rev: fe0206ba482d209b24e636d578aa68ba5e67ba1b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is little point in having "crosssdk" suffex added to the virtual provider within
binutils since the TARGET_PREFIX or SDK_PREFIX already encapsulates this. Remove it
allowing some of the special case overriding to be removed.
(From OE-Core rev: 6856fc5c848cc2564bebe03a007ef109f46d0adb)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This function is referencing '${S}/..'.
It uses ${S} only as good known directory path to start
traversing from, and it does not need it to exist or be populated.
If ${S} does not exist yet, the function will fail because
it cannot evaluate path .. from non-existing directory.
Reproducer (verified in master and kirkstone):
bitbake gcc -c deploy_source_date_epoch
bitbake gcc -c cleansstate
rm -rf build/tmp
bitbake gcc -c deploy_source_date_epoch
(From OE-Core rev: 42661a59cda164b2d236ffc35b4d8cf43312b677)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently if you switch machines, gcc-source do_deploy_source_date_epoch
would re-run as the stamps are tune specific. This hasn't caused much
of an issue until now, however if we fix the gcc recipes to reuse the
timestamp from this task, it does then create problems.
Copy code from allarch to ensure this task hash doesn't change between
machines/tunes.
(From OE-Core rev: 7e052d03464ba5e880a6c5a0e45ff2f467ef97e8)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Whilst we patch gengtype.cc, we don't patch gengtype-lex.cc which would
be the file which would trigger regeneration of files.
The real bug that was likely the cause for this fix is probably SDE issues
with gcc shared workdir so this code can now be dropped.
(From OE-Core rev: 7ab82b5db2a737c2a0266280b15d343a27c0e1d5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The source date epoch for gcc isn't being transferred from the shared
workdir to the current WORKDIR for the specific recipe. This results in
the clamping code within sstate.bbclass using a value from 2011 which
changes the timestamps of many files. Since this happens part way
through the build, if pieces of gcc haven't built, or build/rebuild
later, we see things rebuilding when they should not and for generated
files, races are possible.
Fix this by copying the SDE from the shared workdir into the recipe
workdir.
[YOCTO #14953]
(From OE-Core rev: b996293b4c8ab7ff3ed852045d17290df29205df)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The change in commit e903b29f (gcc-cross: pass
-Werror=poison-system-directories to compiler stages) made it impossible
to disable the error using -Wno-error=poison-system-directories.
(From OE-Core rev: 1cb0245539f7d5277fae4e9abc7f2a0130d0caa8)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
