On Tue, Oct 10, 2023 at 10:37 AM Rasmus Villemoes <
[email protected]> wrote:

> On 10/10/2023 14.31, Bruce Ashfield wrote:
> >
> >
> > On Tue, Oct 10, 2023 at 7:44 AM Rasmus Villemoes
> >     It seems we can fix it with
> >
> >     $ git diff
> >     diff --git a/meta/recipes-kernel/perf/perf.bb <http://perf.bb>
> >     b/meta/recipes-kernel/perf/perf.bb <http://perf.bb>
> >     index 420286e..59c0c10 100644
> >     --- a/meta/recipes-kernel/perf/perf.bb <http://perf.bb>
> >     +++ b/meta/recipes-kernel/perf/perf.bb <http://perf.bb>
> >     @@ -81,7 +81,7 @@ EXTRA_OEMAKE = '\
> >          LDSHARED="${CC} -shared" \
> >          AR="${AR}" \
> >          LD="${LD}" \
> >     -    EXTRA_CFLAGS="-ldw -I${S}" \
> >     +    EXTRA_CFLAGS="-ldw -I${S} ${DEBUG_PREFIX_MAP}" \
> >          YFLAGS='-y
> >
>  --file-prefix-map=${WORKDIR}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}' \
> >          EXTRA_LDFLAGS="${PERF_EXTRA_LDFLAGS}" \
> >          perfexecdir=${libexecdir} \
> >
> >     but I'm quite curious what the difference between our setups is,
> since
> >     apparently the only problem oe-core has/had was that new file
> introduced
> >     in v6.4.
> >
> >
> > You can see any patches that we have against perf in the kernel-cache
> > repository (https://git.yoctoproject.org/yocto-kernel-cache/
> > <https://git.yoctoproject.org/yocto-kernel-cache/>). That being
> > said, we unfortunately cannot really patch perf, since the recipe is
> > supported against more than our reference kernels.
>
> I didn't suggest to patch perf, I suggested to patch the perf recipe.
>

I also didn't mean that. You asked what the differences might
be in our setup, which largely means linux-yocto. Hence why
the patches would be relevant to that question.


> >
> > Other than that, there's no special setup (in particular no setup that
> > I have) as it is the autobuilder infrastructure that typically finds and
> > reports these issues.
>
> So I found the difference, and those autobuilder builds do in fact make
> the compiler use all the right -f*-prefix-map options. It's because
> meta/conf/distro/include/security_flags.inc contains
>
> TARGET_CC_ARCH:append:pn-perf = " ${SELECTED_OPTIMIZATION}"
>
> and that includes the DEBUG_PREFIX_MAP setting, and in turn gets
> included in the CC setting via HOST_CC_ARCH. And of course the poky
> distro includes that security_flags.inc file, while our custom distro
> does not (up until five minutes ago, I never knew that file existed).
>
> Of course one wonders why those :append:pn-* settings that don't
> actually append any security related flags, but do affect stuff like the
> recipes passing QA, are hidden away in a file called security_flags.inc
> instead of those settings just being directly in the recipes themselves.
> There's no explanation in oe-core e93765ffb57 ; it removed a whole bunch
> of append_pn-* stuff which had apparently become redundant (the commit
> log hints as much), but doesn't offer any explanation as to why pn-perf
> should grow that setting. And AFAICT that long predates the invention of
> the -f*-prefix-map flags, so it seems to be mostly by accident that
> perf, with the poky distro, actually does build with those flags.
>

The settings and debug maps are typically distro policies, so that's
why they were historically controlled there. If we pull it out to the
recipe, we'd want to check a similar distro flag to enable/disable
(mainly for debug purposes).

I wouldn't say by accident at all, but there's been a lot of changes
over time, so there's bits and pieces that are stitched together
differently, with variable names that have had their meaning change
over time.

Bruce



>
> Rasmus
>
>

-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end
- "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#188911): 
https://lists.openembedded.org/g/openembedded-core/message/188911
Mute This Topic: https://lists.openembedded.org/mt/100051819/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to