Re: [PATCH v2] kernel-devsrc: restructure for out of tree (and on target) module builds

[Bruce Ashfield <bruce.ashfield@windriver.com>]

On 2018-07-12 1:02 PM, Khem Raj wrote:
> On 7/12/18 7:55 AM, Bruce Ashfield wrote:
>> On 2018-07-12 9:53 AM, Richard Purdie wrote:
>>> On Thu, 2018-07-12 at 09:49 -0400, Bruce Ashfield wrote:
>>>> On 2018-07-10 5:41 PM, Richard Purdie wrote:
>>>>> On Tue, 2018-07-10 at 12:38 -0400, Bruce Ashfield wrote:
>>>>>> On 07/10/2018 06:21 AM, Richard Purdie wrote:
>>>>>>> On Mon, 2018-07-09 at 11:53 -0400, Bruce Ashfield wrote:
>>>>>>
>>>>>> I'll try the other configs, but clearly I have something
>>>>>> different in
>>>>>> my x86-64 build.
>>>>>>
>>>>>> I can't run the self tests directly, but am copying the files
>>>>>> onto my
>>>>>> qemu session and running things myself:
>>>>>>
>>>>>> root@qemux86-64:/lib/modules/4.14.48-yocto-standard/build# make
>>>>>> ARCH=x86
>>>>>> scripts prepare
>>>>>> Makefile:950: "Cannot use CONFIG_STACK_VALIDATION=y, please
>>>>>> install
>>>>>> libelf-dev, libelf-devel or elfutils-libelf-devel"
>>>>>>       CHK     scripts/mod/devicetable-offsets.h
>>>>>>       SYSTBL  arch/x86/include/generated/asm/syscalls_32.h
>>>>>>       SYSHDR  arch/x86/include/generated/asm/unistd_32_ia32.h
>>>>>>       SYSHDR  arch/x86/include/generated/asm/unistd_64_x32.h
>>>>>>       SYSTBL  arch/x86/include/generated/asm/syscalls_64.h
>>>>>>       SYSHDR  arch/x86/include/generated/uapi/asm/unistd_32.h
>>>>>>       SYSHDR  arch/x86/include/generated/uapi/asm/unistd_64.h
>>>>>>       SYSHDR  arch/x86/include/generated/uapi/asm/unistd_x32.h
>>>>>>       HOSTCC  arch/x86/tools/relocs_32.o
>>>>>>       HOSTCC  arch/x86/tools/relocs_64.o
>>>>>>       HOSTCC  arch/x86/tools/relocs_common.o
>>>>>>       HOSTLD  arch/x86/tools/relocs
>>>>>>       CHK     include/config/kernel.release
>>>>>>       CHK     include/generated/uapi/linux/version.h
>>>>>>       CHK     include/generated/utsrelease.h
>>>>>> Makefile:950: "Cannot use CONFIG_STACK_VALIDATION=y, please
>>>>>> install
>>>>>> libelf-dev, libelf-devel or elfutils-libelf-devel"
>>>>>>
>>>>>> root@qemux86-64:/tmp# make
>>>>>> make -C /usr/src/kernel M=/tmp modules
>>>>>> make[1]: Entering directory '/lib/modules/4.14.48-yocto-
>>>>>> standard/build'
>>>>>> Makefile:950: "Cannot use CONFIG_STACK_VALIDATION=y, please
>>>>>> install
>>>>>> libelf-dev, libelf-devel or elfutils-libelf-devel"
>>>>>>       Building modules, stage 2.
>>>>>>       MODPOST 1 modules
>>>>>> make[1]: Leaving directory '/lib/modules/4.14.48-yocto-
>>>>>> standard/build'
>>>>>> root@qemux86-64:/tmp# insmod hellomod.ko
>>>>>> [  419.211616] hellomod: loading out-of-tree module taints
>>>>>> kernel.
>>>>>> [  419.212586] Hello world!
>>>>>>
>>>>>> This is on the core-image-kernel-dev image, which is the one that
>>>>>> I created to test all this.
>>>>>>
>>>>>> What image is that using ? some sato sdk one ?
>>>>>
>>>>> We really need to find you a way to run these. The problem is the
>>>>> qemu
>>>>> graphics piece? You can't have a dummy vncserver or something to
>>>>> direct
>>>>> them at?
>>>>>
>>>>> The image is a core-image-sato-sdk...
>>>>
>>>> I was able to trigger the objtool issue with this image, looking at
>>>> fixing it and the other arches now.
>>>
>>> Since its image related, is it a missing package dependency? Just
>>> curious why its happening with some images but not your test ones...
>>
>> It is. I have extra toolchain elements being installed in
>> core-image-kernel-dev
>> that hold things together (i.e. the kernel's objtool doesn't need to
>> be built).
>>
>> The obvious fix is to just add an RDEPENDS, but I'm being stubborn
>> and trying to make it build on target, since the build of objtool from
>> the kernel source is showing me some sort of include path issue that
>> I'd like to sort out:
>>
>>    CC /lib/modules/4.14.48-yocto-standard/build/tools/objtool/exec-cmd.o
>> exec-cmd.c: In function 'get_pwd_cwd':
>> exec-cmd.c:49:4: error: implicit declaration of function 'strlcpy'; did
>> you mean 'strncpy'? [-Werror=implicit-function-declaration]
>>      strlcpy(cwd, pwd, PATH_MAX);
>>      ^~~~~~~
>>      strncpy
>> exec-cmd.c:49:4: error: nested extern declaration of 'strlcpy'
>> [-Werror=nested-externs]
>> cc1: all warnings being treated as errors
>>
> 
> Kernel has this function defined in tools/include/linux/string.h so
>

Well yes, a grep locates that :D


> however it has it like this
> 
> #if defined(__GLIBC__) && !defined(__UCLIBC__)
> extern size_t strlcpy(char *dest, const char *src, size_t size);
> #endif
> 
> Which means it will not work for musl and we need to ensure that we
> use -D_GNU_SOURCE for it to be included from standard musl headers

I've never built or supported musl, and since this is using the
in kernel Makefiles, etc, it isn't something I can patch or fix
outside of linux-yocto.

I'm just worried about the glibc cases, we can do follow up patches
later.

Bruce

> 
> 
>> Cheers,
>>
>> Bruce
>>
>>>
>>> Cheers,
>>>
>>> Richard
>>>
>>
> 
>