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 ? 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 should check with you first to get the details on how you were testing pahole functionality. Bruce > > 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#181195): https://lists.openembedded.org/g/openembedded-core/message/181195 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] -=-=-=-=-=-=-=-=-=-=-=-
