From: Trent Piepho <xyzzy@speakeasy.org>
To: Linux Kernel Mailing list <linux-kernel@vger.kernel.org>
Cc: Sam Ravnborg <sam@ravnborg.org>,
Mauro Carvalho Chehab <mchehab@infradead.org>,
kbuild-devel@lists.sourceforge.net
Subject: [patch] modpost problem when symbols move from one module to another
Date: Thu, 11 Oct 2007 16:40:10 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.58.0710111631350.13556@shell4.speakeasy.net> (raw)
[-- Attachment #1: Type: TEXT/PLAIN, Size: 218 bytes --]
The v4l-dvb tree recently renamed a module and this caused some problems
with modpost creating incorrect module dependencies. This patch fixes that
problem. It should be explained thoroughly in the patch description.
[-- Attachment #2: Type: TEXT/PLAIN, Size: 1856 bytes --]
modpost: Fix problem with out of date Module.symvers
When part of build an external module tree, modpost first reads in the
kernel's and then the external tree's Module.symvers files. From these files
it establishes a symbol => module mapping. When it later reads in each module
built and processes the symbols it finds, it discovers the symbol=>module
mapping from Module.symvers and leaves it as it is.
The problem comes with a module has been re-named or a symbol has moved from
one module to another, since the Module.symvers file was generated. modpost
does not update the symbol=>module mapping when it finds the new location of
the symbol when scanning the newly built modules. This results in the module
containing incorrect dependency information and the new Module.symvers file
written by modpost will also contain the incorrect mappings, perpetuating the
problem to the next build, and so on.
When building the out of kernel development tree for kernel subsystem, like
v4l-dvb or ALSA, deleting the external Module.symvers file before building
(which the kernel build system doesn't do and shouldn't be necessary anyway),
won't fix the problem. modpost still reads the kernel's Module.symvers, and
since we a building a kernel subsystem, it will define the same symbols as the
external modules.
Signed-off-by: Trent Piepho <xyzzy@speakeasy.org>
diff -r 79f0ea1e0e70 scripts/mod/modpost.c
--- a/scripts/mod/modpost.c Tue Oct 09 21:00:40 2007 +0000
+++ b/scripts/mod/modpost.c Thu Oct 11 15:20:01 2007 -0700
@@ -268,6 +268,9 @@ static struct symbol *sym_add_exported(c
"was in %s%s\n", mod->name, name,
s->module->name,
is_vmlinux(s->module->name) ?"":".ko");
+ } else {
+ /* In case Modules.symvers was out of date */
+ s->module = mod;
}
}
s->preloaded = 0;
next reply other threads:[~2007-10-11 23:40 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-11 23:40 Trent Piepho [this message]
2007-10-18 11:46 ` Sam Ravnborg
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=Pine.LNX.4.58.0710111631350.13556@shell4.speakeasy.net \
--to=xyzzy@speakeasy.org \
--cc=kbuild-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab@infradead.org \
--cc=sam@ravnborg.org \
/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®