From: Hope Sneddon <hope.sneddon@outlook.com>
To: "poky@lists.yoctoproject.org" <poky@lists.yoctoproject.org>
Subject: [poky][kirkstone][clang] Poky Clang Toolchain with Code Coverage Flags
Date: Wed, 1 May 2024 02:11:38 +0000 [thread overview]
Message-ID: <SL2P216MB127765CAD0578E6FEFE0D5D399192@SL2P216MB1277.KORP216.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <3ddbb9d89bfe40648aa48ffd376c4f0a@boeing.com>
[-- Attachment #1: Type: text/plain, Size: 1728 bytes --]
Hi Poky Community,
This is a separate issue as another issue uncovered from discussion item originally prompted by submission #13328 (Compiling Poky with Clang and Clang Coverage Flags)<https://lists.yoctoproject.org/g/poky/message/13328>.
The issue is, when poky builds are intended to be compiled using the clang/ LLVM toolchain with full code coverage via setting the following in local.conf (and including the meta-clang layer):
TOOLCHAIN = "clang"
TARGET_CPPFLAGS:prepend:class-target:toolchain-clang = "-fprofile-instr-generate -fcoverage-mapping "
RUNTIME = "llvm"
CLANGSDK = "1"
While these scoped coverage compiler flags are required to ensure that any packages that are non-clangable can fall back to compiling with GCC, building either a single package (bash using command bitbake bash) or an image (using bitbake core-image-minimal) results in everything being successfully compiled using GCC (i.e. clang never being deemed appropriate used as the compiler).
More concerningly, bitbaking this example package/ image with the meta-clang layer completely deleted from the poky repo does not result in a failure to build either item (seeming to suggest there is no dependency on meta-clang content from the clang compiler/ toolchain).
Please note all of the above has been done on the Poky Kirkstone distribution as Scarthgap was not officially released at the time of this testing (conducted April 26th-30th) and this was also to mitigate any possible patch lag in meta-clang to align it with the Scarthgap release.
Any guidance on rectifying this setup to ensure all possible packages are successfully built as full code-coverage instrumented clang outputs would be much appreciated.
Thank you,
Hope
[-- Attachment #2: Type: text/html, Size: 3005 bytes --]
next parent reply other threads:[~2024-05-01 2:11 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <3ddbb9d89bfe40648aa48ffd376c4f0a@boeing.com>
2024-05-01 2:11 ` Hope Sneddon [this message]
2024-05-01 3:20 ` [poky][kirkstone][clang] Poky Clang Toolchain with Code Coverage Flags Khem Raj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=SL2P216MB127765CAD0578E6FEFE0D5D399192@SL2P216MB1277.KORP216.PROD.OUTLOOK.COM \
--to=hope.sneddon@outlook.com \
--cc=poky@lists.yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).