Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Rasmus Villemoes <rasmus.villemoes@prevas.dk>,
	 openembedded-core@lists.openembedded.org
Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
Subject: Re: [OE-core] [PATCH] perf: lift TARGET_CC_ARCH modification out of security_flags.inc
Date: Fri, 20 Oct 2023 10:38:56 +0100	[thread overview]
Message-ID: <64a231dc3d22dfd4eb33ac10f107997dfc7477f6.camel@linuxfoundation.org> (raw)
In-Reply-To: <1603003d-f5a4-4293-88f0-4b1ea006404b@prevas.dk>

On Fri, 2023-10-20 at 10:10 +0200, Rasmus Villemoes wrote:
> On 19/10/2023 14.48, Richard Purdie wrote:
> > On Thu, 2023-10-19 at 14:32 +0200, Rasmus Villemoes via
> > lists.openembedded.org wrote:
> > > From: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
> > > 
> > > Building perf without security_flags.inc being included in one's
> > > distro results in the buildpaths warning
> > > 
> > > WARNING: perf-1.0-r9 do_package_qa: QA Issue: File /usr/bin/trace in
> > > package perf contains reference to TMPDIR
> > > 
> > > because the ${DEBUG_PREFIX_MAP} does not get used. Most recipes get
> > > that from CFLAGS, but the perf recipe explicitly unsets that.
> > > 
> > > Now ${SELECTED_OPTIMIZATION} of course contains more than just
> > > ${DEBUG_FLAGS}/${DEBUG_PREFIX_MAP}. For most TUs, perf's build system
> > > adds its own optimization flags (-O6 for odd reasons), so for those
> > > including the -O2 or -Og doesn't change anything. But looking at the
> > > .o.cmd files show that there are some TUs which currently get built
> > > without any -O flag. So for those adding the distro's
> > > SELECTED_OPTIMIZATION seem to be the right thing to do.
> > > 
> > > Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
> > > ---
> > >  meta/conf/distro/include/security_flags.inc | 1 -
> > >  meta/recipes-kernel/perf/perf.bb            | 1 +
> > >  2 files changed, 1 insertion(+), 1 deletion(-)
> > 
> > The fact this works suggests perf is ignoring TARGET_CFLAGS. Is there
> > anything in the perf build system where we should be passing in cflags
> > we really want used?
> 
> Well, IIUC, the normal way TARGET_CFLAGS would take effect is via the
> 'export CFLAGS = "${TARGET_CFLAGS}'. But in the perf recipe, both
> do_compile and do_install start with
> 
>         # Linux kernel build system is expected to do the right thing
>         unset CFLAGS
> 
> And perf's build system does indeed add lots of flags of its own, at
> least for most TUs, but nowhere is any -f(macro/debug/file)-prefix being
> set.
> 
> So I do think that TARGET_CC_ARCH is the best place for flags that we
> really want used. At least as an initial step, because this is known to
> work when using the security_flags.inc file. Maybe there's some cleaner
> way where we don't unset CFLAGS, but that could be a giant can of worms.
> 
> And yes, a comment should be added. Is something like
> 
> # Perf's build system adds its own optimization flags for most TUs,
> # overriding the flags included here. But for some, perf does not add
> # any -O option, so ensure the distro's chosen optimization gets used
> # for those. Since ${SELECTED_OPTIMIZATION} always includes
> # ${DEBUG_FLAGS} which in turn includes ${DEBUG_PREFIX_MAP}, this also
> # ensures perf is built with appropriate -f*-prefix-map options,
> # avoiding the 'buildpaths' QA warning.
> 
> too verbose?

If it were me I'd probably write:

# The perf makefile has "unset CFLAGS" as "Linux kernel build system is
# expected to do the right thing". It doesn't and we need our prefix 
# map options and security flags amongst other things so force our 
# cflags in.

Cheers,

Richard






  reply	other threads:[~2023-10-20  9:39 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-19 12:32 [PATCH] perf: lift TARGET_CC_ARCH modification out of security_flags.inc Rasmus Villemoes
2023-10-19 12:40 ` Bruce Ashfield
2023-10-19 12:48 ` [OE-core] " Richard Purdie
2023-10-20  8:10   ` Rasmus Villemoes
2023-10-20  9:38     ` Richard Purdie [this message]
2023-10-20 10:03       ` Rasmus Villemoes
2023-10-20 10:13         ` Richard Purdie
2023-10-20 11:19           ` Rasmus Villemoes
2023-10-20 12:52             ` Bruce Ashfield
2023-10-20 14:24               ` Richard Purdie
2023-10-20 15:07                 ` Bruce Ashfield

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=64a231dc3d22dfd4eb33ac10f107997dfc7477f6.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=bruce.ashfield@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=rasmus.villemoes@prevas.dk \
    /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