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. 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 > > 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 (#181249): https://lists.openembedded.org/g/openembedded-core/message/181249 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] -=-=-=-=-=-=-=-=-=-=-=-
