Messages in this thread | | | Date | Wed, 1 Apr 2020 10:00:34 +0200 | From | Jessica Yu <> | Subject | Re: [PATCH v2] modpost: move the namespace field in Module.symvers last |
| |
+++ John Stultz [31/03/20 15:09 -0700]: >On Tue, Mar 31, 2020 at 2:58 AM Jessica Yu <jeyu@kernel.org> wrote: >> +++ John Stultz [30/03/20 23:25 -0700]: >> >On Mon, Mar 30, 2020 at 10:49 PM John Stultz <john.stultz@linaro.org> wrote: >> >> The only difference I can find is that the Module.symvers in the >> >> external module project doesn't seem to have a tab at the end of each >> >> line (where as Module.symvers for the kernel - which doesn't seem to >> >> have any namespace names - does). >> >> >> >> Is there something I need to tweak on the external Kbuild to get >> >> Module.symvers to be generated properly (with the empty tab at the >> >> end) for this new change? >> >> Or does the parser need to be a bit more flexible? >> >> >> > >> >One extra clue on this: I noticed the external module Makefile had >> >KBUILD_EXTRA_SYMBOLS="$(EXTRA_SYMBOLS)" in the $(MAKE) string, where >> >EXTRA_SYMBOLS pointed to some files that no longer exist. I removed >> >the KBUILD_EXTRA_SYMBOLS= argument, and magically, the generated >> >Module.symvers now had tabs at the end of each line. >> > >> >I wonder if there some path in the KBUILD_EXTRA_SYMBOLS= handling that >> >isn't generating the output in the same way? >> >> I'm afraid we're going to need some specifics on reproducing this >> issue. Could you provide a reproducer or steps on how to reproduce? I >> have not been able to trigger this problem even with >> KBUILD_EXTRA_SYMBOLS pointing to an invalid path (I also tested with >> valid paths). >> >> I tested with a skeleton external module that exports two functions, >> one with a namespace and one without. I built this module against the >> latest v5.6 kernel. The generated Module.symvers was correct - the >> namespaced function had the namespace at the end and the other >> function without a namespace had a tab at the end. >> >> I also tested with two external modules, one with a symbol dependency >> on the other, so KBUILD_EXTRA_SYMBOLS usage is required here. The >> generated Module.symvers was also correct here. >> >> The only advice I can offer at this time is that all external modules >> must be built against the new kernel to generate a correctly formated >> Module.symvers file. If you have any KBUILD_EXTRA_SYMBOLS pointing to >> an outdated Module.symvers file for example, you will see the "FATAL: >> parse error in symbol dump file" error. > >Well, my apologies. :( In the light of day, this isn't reproducing >anymore. I'm a bit at a loss as to why I was tripping over it so >regularly before, but I suspect something in the build is leaving a >stale Modules.symvers around from before this patch landed. > >Terribly sorry for the noise.
No problem, thank for reporting back!
Jessica
| |