From: Randy Dunlap <rdunlap@infradead.org>
To: Thomas Zimmermann <tzimmermann@suse.de>,
Naresh Kamboju <naresh.kamboju@linaro.org>,
dri-devel@lists.freedesktop.org,
open list <linux-kernel@vger.kernel.org>,
Linux-Next Mailing List <linux-next@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
Andrey Konovalov <andreyknvl@gmail.com>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Arnd Bergmann <arnd@arndb.de>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
Linus Walleij <linus.walleij@linaro.org>,
Arnd Bergmann <arnd@arndb.de>
Subject: Re: gpu: drm_fb_cma_helper.c:46: undefined reference to `drm_gem_fb_get_obj'
Date: Tue, 26 Oct 2021 17:58:34 -0700 [thread overview]
Message-ID: <6862b109-ea12-6ffa-c82b-b23ee26aa5b2@infradead.org> (raw)
In-Reply-To: <857ab1a9-0175-2b2c-e729-2620d0221e1e@suse.de>
On 10/26/21 11:21 AM, Thomas Zimmermann wrote:
> Hi
>
> Am 25.10.21 um 14:13 schrieb Naresh Kamboju:
>> Regression found on arm gcc-11 built with multi_v5_defconfig
>> Following build warnings / errors reported on linux next 20211025.
>>
>> metadata:
>> git_describe: next-20211025
>> git_repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next
>> git_short_log: 9ae1fbdeabd3 (\"Add linux-next specific files for 20211025\")
>> target_arch: arm
>> toolchain: gcc-11
>> config: multi_v5_defconfig
>>
>> build error :
>> --------------
>> arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.o: in
>> function `drm_fb_cma_get_gem_obj':
>> drivers/gpu/drm/drm_fb_cma_helper.c:46: undefined reference to
>> `drm_gem_fb_get_obj'
>> arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.c:46:
>> undefined reference to `drm_gem_fb_get_obj'
>> arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.c:46:
>> undefined reference to `drm_gem_fb_get_obj'
>> arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.o: in
>> function `drm_fb_cma_sync_non_coherent':
>> drivers/gpu/drm/drm_fb_cma_helper.c:133: undefined reference to
>> `drm_atomic_helper_damage_iter_init'
>> arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.c:135:
>> undefined reference to `drm_atomic_helper_damage_iter_next'
>> make[1]: *** [Makefile:1252: vmlinux] Error 1
>> make[1]: Target '__all' not remade because of errors.
>> make: *** [Makefile:226: __sub-make] Error 2
>>
>> Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
>>
>>
>> build link:
>> -----------
>> https://builds.tuxbuild.com/1zzgFZBGjpQ5R0lawQFW9iJ39Hp/build.log
>>
>> build config:
>> -------------
>> https://builds.tuxbuild.com/1zzgFZBGjpQ5R0lawQFW9iJ39Hp/config
>
> Looking at this config, there is:
>
> CONFIG_DRM=y
> # CONFIG_DRM_DP_AUX_CHARDEV is not set
> # CONFIG_DRM_DEBUG_MM is not set
> # CONFIG_DRM_DEBUG_SELFTEST is not set
> CONFIG_DRM_KMS_HELPER=m
> # CONFIG_DRM_LOAD_EDID_FIRMWARE is not set
> # CONFIG_DRM_DP_CEC is not set
> CONFIG_DRM_GEM_CMA_HELPER=y
> CONFIG_DRM_KMS_CMA_HELPER=y
>
> GEM_CMA_HELPER depends on KMS_HELPER, but the latter is a module. That's probably the cause of the problem. Is it intentionally set this way?
>
The only drivers that select DRM_KMS_HELPER are both =m, so that's how
DRM_KMS_HELPER is set also.
Symbol: DRM_KMS_HELPER [=m]
Type : tristate
Defined at drivers/gpu/drm/Kconfig:82
Depends on: HAS_IOMEM [=y] && DRM [=y]
Selected by [m]:
- DRM_ATMEL_HLCDC [=m] && HAS_IOMEM [=y] && DRM [=y] && OF [=y] && COMMON_CLK [=y] && MFD_ATMEL_HLCDC [=y] && ARM [=y]
- DRM_ASPEED_GFX [=m] && HAS_IOMEM [=y] && DRM [=y] && OF [=y] && (COMPILE_TEST [=n] || ARCH_ASPEED [=y]) && MMU [=y]
I did the ARM cross-build and also see the linker error.
I didn't understand why -- and still don't, but here is a little
speculation:
In the past (e.g. 10 years ago), we have to move some .o files
in lib/ from lib-y to obj-y so that they would always be included
in the final object file and not cause their user/caller object
files to suffer from undefined references.
These happened because unused functions(?) in lib-y files are
stripped out of the final object files.
The same thing could be happening here (still just guessing).
Does that help any? I dunno.
Adding Arnd to Cc: to see if he has any ideas...
>>
>> # To install tuxmake on your system globally
>> # sudo pip3 install -U tuxmake
>> tuxmake --runtime podman --target-arch arm --toolchain gcc-11
>> --kconfig multi_v5_defconfig
>>
>> --
>> Linaro LKFT
>> https://lkft.linaro.org
--
~Randy
next prev parent reply other threads:[~2021-10-27 0:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-25 12:13 Naresh Kamboju
2021-10-25 14:01 ` Naresh Kamboju
2021-10-26 17:59 ` Thomas Zimmermann
2021-10-27 2:56 ` Naresh Kamboju
2021-10-25 18:25 ` Thomas Zimmermann
2021-10-26 18:21 ` Thomas Zimmermann
2021-10-27 0:58 ` Randy Dunlap [this message]
2021-10-27 6:19 ` Arnd Bergmann
2021-10-27 6:26 ` Randy Dunlap
2021-10-27 6:50 ` Arnd Bergmann
2021-10-27 8:08 ` Thomas Zimmermann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6862b109-ea12-6ffa-c82b-b23ee26aa5b2@infradead.org \
--to=rdunlap@infradead.org \
--cc=airlied@linux.ie \
--cc=alexandre.belloni@bootlin.com \
--cc=andreyknvl@gmail.com \
--cc=arnd@arndb.de \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=naresh.kamboju@linaro.org \
--cc=sfr@canb.auug.org.au \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®