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