Hi Bruce,
On 5/15/23 21:11, Bruce Ashfield wrote:
CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know
the content is safe.
On Mon, May 15, 2023 at 8:34 AM Bruce Ashfield via
lists.openembedded.org
<[email protected]> wrote:
On Mon, May 15, 2023 at 6:04 AM Xiangyu Chen
<[email protected]> wrote:
Hi Bruce,
Sorry for being late..
On 5/13/23 09:16, Bruce Ashfield wrote:
CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know
the content is safe.
On Fri, May 12, 2023 at 10:47 AM Bruce Ashfield via
lists.openembedded.org
<[email protected]> wrote:
On Wed, May 10, 2023 at 10:23 PM Xiangyu Chen
<[email protected]> wrote:
Hi Richard and Bruce,
Thanks for your suggestion,
On 5/11/23 00:25, Bruce Ashfield wrote:
CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know
the content is safe.
On Wed, May 10, 2023 at 12:16 PM Richard Purdie
<[email protected]> wrote:
On Mon, 2023-05-08 at 09:33 +0800, Xiangyu Chen wrote:
From: Xiangyu Chen <[email protected]>
after enable the kernel CONFIG_DEBUG_INFO_BTF in devshell, the make would
report some
errors due to pahole and elfuitls is missing, since this is a debug option, so
conditionally
add an option named "btf" in KERNEL_DEBUG_OPTIONS, if someone need enable
CONFIG_DEBUG_INFO_BTF
option in devshell, they can add KERNEL_DEBUG_OPTIONS += "btf" in local.conf to
solve the pahole
and elfutils dependency.
Is this a defined workflow somewhere? Is KERNEL_DEBUG_OPTIONS with this
option documented somewhere?
I also think the mention of devshell in the commit message is
misleading, this issue happens regardless of how you enable the option.
There are also other ways of enabling this than local.conf, you'd
likely not want people doing that at the end of development.
I'm curious on Bruce's opinion but to me this at the very least needs a
commit message rewrite and I'd question whether the docs elsewhere
would allow someone to discover this workflow anyway.
I missed this entirely, thanks for replying to it, or I never would
have noticed.
This mechanism isn't appropriate for these dependencies. I only added
it to work around pkgconfig issues (which we can more cleanly solve in
newer kernels (see what I've been doing with make-mod-scripts) .. so
it can eventually be dropped).
We are already enabling elfutils-native conditionally on a
per-architecture basis (currently only x86-64).
If we need it on more arches now, we should enable it in the version
specific recipes, or actually, we have moved far enough into newer
kernel's that it could be in the .inc now.
This commit's background was some kernel debug options needs elfutils
and pahole native package, since the issue happens on enabling kernel
debug options and not all people needs it, so I conditionally add the
dependency in KERNEL_DEBUG_OPTION.
If possible we can enable it in .inc because newer kernel tools like btf
are support using pkg-config to locate the libelf instead of finding it
from /usr/ folder, so we can use elfutils-natvie instead of installing
elfutils package on host PC.
Similarly, we should enable the pahole-native dependency on a per-arch basis.
As Richard mentioned, what's the reproducer to see the errors ? it
must be more than devshell.
Yes, this happens on devshell and normal world if some kernel debug
options are enabled. We can reproduce this issue with following steps(I
have found the issue with kernel 5.15):
1. enable kernel option CONFIG_DEBUG_KERNEL CONFIG_DEBUG_INFO and
CONFIG_DEBUG_INFO_BTF
2. build the kernel image, the compiler would report missing libelf.h
and gelf.h which contains in elfutils-native(this step not happens on
x86-64 due to it has been enabled).
3. enable elfutils-native by manual, the kernel source code can be
compiled successfully but failed in final step due to missing pahole.
If you can follow up with the steps to reproduce, I can take on the
refactoring and broader dependency cleanup question, since I can test
the wider matrix at the same time.
Thanks, my local setup might missing some corner case, this is another
reason I enable those native packages limit in KERNEL_DEBUG_OPTION :).
I've been thinking about this, and I've come to the following suggestion:
I plan on moving the elfutils-native to linux-yocto.inc, out of the
version specific
recipes. I'll also drop the architecture specific nature of the
current DEPENDS.
The need for this is much more common now, and all of the reference kernels
in master are new enough. The elfutils-native build dependency is not
significant
enough to worry about adding it for all architectures. If it does
become a problem,
there are options to make it conditional again.
I can drop the HOST_LIBELF_LIBS work around in the linux-yocto.inc, as
we can now properly detect libelf via pkg-config. I didn't need it in any of
my testing. Again, if this proves to be wrong, I'd enable it in a
different way now
(using what I've learned from fixing make-mod-scripts).
As for the pahole-native dependency, there's been a "developer" kernel-type
for quite some time. The design intention behind it was to enable options like
this, and not make the "standard" or "production" kernel's too large by default.
So the dependency could be conditional on that kernel type ... but we don't
want to break other kernels just because they've enabled that option. We also
don't (and won't) get into the game of looking for individual options in the
.config to enable something, since a) it is too late b) it is a moving target.
So that leaves the following options: a) enable pahole-native unconditionally
on the arches that support it (x86-64, aarch64) (and also move the pahole
recipe into oe-core) b) make the KERNEL_DEBUG_OPTIONS less specific,
and simply call it KERNEL_DEBUG, when enabled, we could conditionally
add pahole-native (I'd also submit documentation for the functionality
c) something I haven't thought about ...
I'm moving on the implementation now, but will adjust course if
there's something
I've missed.
I have my implementation done, but I'm wondering what your configuration
was for testing pahole ?
My reply will be hard to read, as plain text reply to the html doesn't
give us proper
context indenting.
I have tested on a devshell, with oe-master branch, the kernel version using
5.15
1. enable pahole-native and elfutils-native in linux-yocto.inc as a dependency.
2. enable CONFIG_DEBUG_KERNEL CONFIG_DEBUG_INFO and
CONFIG_DEBUG_INFO_BTF under menuconfig
3. using "export PKG_CONFIG_SYSROOT_DIR=""" cleanning PKG_CONFIG_SYSROOT_DIR
4, make
If the test environment using bitbake, then we need to remove PAHOLE=false flag
in kernel EXTRA_OEMAKE in classes-recipe/kernel.bbclass, otherwise, bitbake
would report missing pahole error.
That's the same as my patch series (I've also changed PAHOLE=false to
a conditional in my series).
I'm seeing the following in qemux86-64 at the end of the build:
| Unsupported DW_TAG_unspecified_type(0x3b)
| Encountered error while encoding BTF.
| LD .tmp_vmlinux.kallsyms1
| NM .tmp_vmlinux.kallsyms1.syms
| KSYMS .tmp_vmlinux.kallsyms1.S
| AS .tmp_vmlinux.kallsyms1.S
| LD .tmp_vmlinux.kallsyms2
| NM .tmp_vmlinux.kallsyms2.syms
| KSYMS .tmp_vmlinux.kallsyms2.S
| AS .tmp_vmlinux.kallsyms2.S
| LD vmlinux
| BTFIDS vmlinux
| FAILED: load BTF from vmlinux: No such file or directory
| make[1]: ***
[/opt/poky/build/tmp/work-shared/qemux86-64/kernel-source/scripts/Makefile.vmlinux:34:
vmlinux] Error 255
| make[1]: *** Deleting file 'vmlinux'
| make: ***
[/opt/poky/build/tmp/work-shared/qemux86-64/kernel-source/Makefile:1255:
vmlinux] Error 2
I haven't looked into it at all yet (but will do so over the weekend)
.. but I thought
I haven't seen this problem yet(i'll pull the latest oe-core and meta-oe code
and try again), if possible, could you share a patch with me so that we can
test it together? thanks.
I'm on oe-core master, with qemux86-64.
I'll do a bit more work on the patch today, and can share it if I
can't figure out where that unsupported tag is coming from.
It seems like it is a known issue, I found both a lkml thread and
debian bug from October 2022.
Your 5.15 kernel wouldn't show the issue.
Yes, this should not happens on 5.15 kernel.
Today I synced the oe-core/poky to latest master version, removed the
build dir and run oe-init-build-env again and switched to use default
linux 6.1.25 instead of 5.15.
Some kernel config has been updated, there is no CONFIG_DEBUG_INFO, I
used CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT.
So, currently my local setup kernel config is enabled
CONFIG_DEBUG_KERNEL CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT and
CONFIG_DEBUG_INFO_BTF, in order to make a easy test, I enabled
elfutils-native and pahole-native as DEPEND directly in linux-yocto.in,
and remove the PAHOLE=false in EXTRA_OEMAKE.
my oe-core rev: 35e5d29a7d654fc79bdb898d0f1fb277270dbfd5
my meta-oe rev:b7aa66d734b911737b61610c1c47778e14b15c55
When I ran bitbake linux-yocto -v -D, I have met the same issue,
| Unsupported DW_TAG_unspecified_type(0x3b)
| Encountered error while encoding BTF.
It's bit strange that the I removed my local OS(ubuntu)'s pahole and the
code can be compiled without error:
CC init/version-timestamp.o
LD .tmp_vmlinux.btf
BTF .btf.vmlinux.bin.o
LD .tmp_vmlinux.kallsyms1
NM .tmp_vmlinux.kallsyms1.syms
KSYMS .tmp_vmlinux.kallsyms1.S
AS .tmp_vmlinux.kallsyms1.S
LD .tmp_vmlinux.kallsyms2
NM .tmp_vmlinux.kallsyms2.syms
KSYMS .tmp_vmlinux.kallsyms2.S
AS .tmp_vmlinux.kallsyms2.S
LD vmlinux
BTFIDS vmlinux
NM System.map
SORTTAB vmlinux
You can find a link to the lkml thread from the debian bug:
https://www.mail-archive.com/[email protected]/msg1873553.html
I'll clean up my patch, since this isn't something I can fix immediately.
If you do track down patches in the latest kernel that haven't been
sent to -stable, we can backport them to fix the linux-yocto builds
with pahole.
Bruce
Br,
Xiangyu
Bruce
I should check with you first to get the details on how you were testing pahole
functionality.
Bruce
Br,
Xiangyu
Bruce
Xiangyu
Bruce
Cheers,
Richard
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
--
- 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 (#181403):
https://lists.openembedded.org/g/openembedded-core/message/181403
Mute This Topic: https://lists.openembedded.org/mt/98753313/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
