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. 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#181248): https://lists.openembedded.org/g/openembedded-core/message/181248 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] -=-=-=-=-=-=-=-=-=-=-=-
