On Tue, May 16, 2023 at 4:56 AM Xiangyu Chen <xiangyu.c...@eng.windriver.com> wrote: > > 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 > > <bruce.ashfield=gmail....@lists.openembedded.org> wrote: > >> On Mon, May 15, 2023 at 6:04 AM Xiangyu Chen > >> <xiangyu.c...@eng.windriver.com> 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 > >>> <bruce.ashfield=gmail....@lists.openembedded.org> wrote: > >>> > >>> On Wed, May 10, 2023 at 10:23 PM Xiangyu Chen > >>> <xiangyu.c...@eng.windriver.com> 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 > >>> <richard.pur...@linuxfoundation.org> wrote: > >>> > >>> On Mon, 2023-05-08 at 09:33 +0800, Xiangyu Chen wrote: > >>> > >>> From: Xiangyu Chen <xiangyu.c...@windriver.com> > >>> > >>> 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 >
Indeed! What's the toolchain version on your ubuntu install ? It is likely either our toolchain version or configuration in combination with the kernel version that is adding the section that pahole can't understand/decode. If you want to work with my patches, you can find my branch here: https://git.yoctoproject.org/poky-contrib/log/?h=zedd/kernel (you also need the linux-yocto bumps on that branch as they'll contain the kernel-cache SRCREV bumps to pick up the fragments for BTF, etc). Bruce > > > > > > You can find a link to the lkml thread from the debian bug: > > https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/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 -- - 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 (#181405): https://lists.openembedded.org/g/openembedded-core/message/181405 Mute This Topic: https://lists.openembedded.org/mt/98753313/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
