Hi everybody, I just joined the LKML!
Don't worry, this is not just a test message, I do actually have
something to say. I just compiled 2.6.11-rc5-mm1 and got undefined
symbols "match_int", "match_octal", "match_token", and "match_strdup" in
several modules. This is using binutils 2.15 and gcc 3.4.4 from Debian.
I grepped around and found those functions in lib/parser.c, so I just
looked at the output of "make V=1" and invoked "ld" manually, adding in
lib/lib.a, and the modules work fine now. However, I don't know enough
about the kernel build process to make a patch to fix this, so I'm just
notifying people of the problem.
BTW, I just got a new hard disk and put Reiser4 on it. It works great!
Keep up the good work guys!
Keenan Pepper <[email protected]> wrote:
>
> I just compiled 2.6.11-rc5-mm1 and got undefined
> symbols "match_int", "match_octal", "match_token", and "match_strdup" in
> several modules.
Please send me your .config file.
I have the exact same problem.
.config is attached
(this may be a debian specific problem as I'm running debian too)
Regards,
Vincent
On Wed, 2 Mar 2005 01:23:31 -0800, Andrew Morton <[email protected]> wrote:
> Keenan Pepper <[email protected]> wrote:
> >
> > I just compiled 2.6.11-rc5-mm1 and got undefined
> > symbols "match_int", "match_octal", "match_token", and "match_strdup" in
> > several modules.
>
> Please send me your .config file.
Vincent Vanackere <[email protected]> wrote:
>
> I have the exact same problem.
> .config is attached
> (this may be a debian specific problem as I'm running debian too)
OK, there are no vmlinux references to lib/parser.o's symbols. So it isn't
getting linked in.
In lib/Makefile, remove parser.o from the lib-y: rule and add
obj-y += parser.o
Works fine for me now, thanks !
Vincent
On Wed, 2 Mar 2005 03:24:14 -0800, Andrew Morton <[email protected]> wrote:
> OK, there are no vmlinux references to lib/parser.o's symbols. So it isn't
> getting linked in.
>
> In lib/Makefile, remove parser.o from the lib-y: rule and add
>
> obj-y += parser.o
On Wed, Mar 02, 2005 at 03:24:14AM -0800, Andrew Morton wrote:
> Vincent Vanackere <[email protected]> wrote:
> >
> > I have the exact same problem.
> > .config is attached
> > (this may be a debian specific problem as I'm running debian too)
>
> OK, there are no vmlinux references to lib/parser.o's symbols. So it isn't
> getting linked in.
That much I figured out after Vincent sent his bug report two weeks ago.
> In lib/Makefile, remove parser.o from the lib-y: rule and add
>
> obj-y += parser.o
This I didn't find.
Is it really the intention to silently omit objects that are not
referenced or could this be changed?
Why doesn't an EXPORT_SYMBOL create a reference?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Oops, should have read all the messages before posting!
I'll try the fix you said, I knew it'd be something like that.
>
> It's attached.
>
> BTW, is attaching things like this the preferred method?
>
Adrian Bunk <[email protected]> wrote:
>
> > In lib/Makefile, remove parser.o from the lib-y: rule and add
> >
> > obj-y += parser.o
>
> This I didn't find.
>
> Is it really the intention to silently omit objects that are not
> referenced or could this be changed?
In some cases, yes, it it desirable. For example, lib/extable.c provides a
default implementation of an exception table sorter but if the architecture
defies its own, the linker will skip the default version in lib/.
At least, that's what the thinking was a few years ago. But it's such a
special-case that we can probably forget about it and just drive the build
and linkage with config now.
> Why doesn't an EXPORT_SYMBOL create a reference?
It does, but that reference is within the same compilation unit as the
definition. IOW: there are no references to the symbol which are external
to the symbol's file. There's still nothing to drag that file in.
On Wed, 02 Mar 2005 08:28:46 PST, Andrew Morton said:
> Adrian Bunk <[email protected]> wrote:
> > Why doesn't an EXPORT_SYMBOL create a reference?
>
> It does, but that reference is within the same compilation unit as the
> definition. IOW: there are no references to the symbol which are external
> to the symbol's file. There's still nothing to drag that file in.
I just got bit by a similar issue myself last night. Had a working 2.6.11-rc5-mm1 tree
compiled with gcc 3.4. Then Fedora-devel had an update to gcc 4.0, so I
rebuilt the *same exact tree* with it, and it threw 3 errors at me, for
exit_orinoco() in drivers/net/wireless/orinoco.c and init_hermes() and exit_hermes()
in drivers/net/wireless/hermes.c. Here's what the code looked like:
(hermes.c)
static int __init init_hermes(void)
{
return 0;
}
static void __exit exit_hermes(void)
{
}
module_init(init_hermes);
module_exit(exit_hermes);
That's it. As far as I can tell, gcc 4.0 semi-correctly determined they were both
static functions with no side effect, threw them away, and then the module_init
and module_exit threw undefined symbols for them.
My totally incorrect workaround was to stick a printk(KERN_DEBUG) in the body
of the 3 trimmed functions so they had side effects.
Anybody got a *better* solution?
[email protected] wrote:
>
> (hermes.c)
> static int __init init_hermes(void)
> {
> return 0;
> }
>
> static void __exit exit_hermes(void)
> {
> }
>
> module_init(init_hermes);
> module_exit(exit_hermes);
>
> That's it. As far as I can tell, gcc 4.0 semi-correctly determined they were both
> static functions with no side effect, threw them away, and then the module_init
> and module_exit threw undefined symbols for them.
>
> My totally incorrect workaround was to stick a printk(KERN_DEBUG) in the body
> of the 3 trimmed functions so they had side effects.
>
> Anybody got a *better* solution?
uh, maybe
static int __init init_hermes(void)
{
asm("");
return 0;
}
then raise a gcc bug report?
On Wed, Mar 02, 2005 at 08:28:46AM -0800, Andrew Morton wrote:
> Adrian Bunk <[email protected]> wrote:
> >
> > > In lib/Makefile, remove parser.o from the lib-y: rule and add
> > >
> > > obj-y += parser.o
> >
> > This I didn't find.
> >
> > Is it really the intention to silently omit objects that are not
> > referenced or could this be changed?
>
> In some cases, yes, it it desirable. For example, lib/extable.c provides a
> default implementation of an exception table sorter but if the architecture
> defies its own, the linker will skip the default version in lib/.
>
> At least, that's what the thinking was a few years ago. But it's such a
> special-case that we can probably forget about it and just drive the build
> and linkage with config now.
>...
lib/extable.c already uses two ARCH_HAS_* defines, simply because the
linker couldn't help if only one of two functions in a file were needed.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Wed, 2005-03-02 at 12:23 -0500, [email protected] wrote:
> static int __init init_hermes(void)
> {
> return 0;
> }
>
> static void __exit exit_hermes(void)
> {
> }
>
> module_init(init_hermes);
> module_exit(exit_hermes);
>
> That's it. As far as I can tell, gcc 4.0 semi-correctly determined they were both
> static functions with no side effect, threw them away, and then the module_init
> and module_exit threw undefined symbols for them.
As a module, we create a non-static alias for "init_hermes", called
"init_module", effectively making it non-static. GCC should not
eliminate it in this case. Similar with module_exit().
For non-modules, we have __attribute_used__.
Rusty.
--
A bad analogy is like a leaky screwdriver -- Richard Braakman
On Wed, 2005-03-02 at 15:00 +0100, Adrian Bunk wrote:
> Why doesn't an EXPORT_SYMBOL create a reference?
It does: EXPORT_SYMBOL(x) drops the address of "x", including
__attribute_used__, in the __ksymtab section.
However, if CONFIG_MODULES=n, it does nothing: perhaps that is what you
are seeing.
Rusty.
--
A bad analogy is like a leaky screwdriver -- Richard Braakman
On Fri, Mar 04, 2005 at 09:23:17PM +1100, Rusty Russell wrote:
> On Wed, 2005-03-02 at 15:00 +0100, Adrian Bunk wrote:
> > Why doesn't an EXPORT_SYMBOL create a reference?
>
> It does: EXPORT_SYMBOL(x) drops the address of "x", including
> __attribute_used__, in the __ksymtab section.
>
> However, if CONFIG_MODULES=n, it does nothing: perhaps that is what you
> are seeing.
That's not the problem.
And it has nothing to do with any gcc 4.0 issues mentioned in this
thread - I saw this problem with gcc 3.3 .
Try the attached .config in 2.6.11-rc4-mm1 (not in 2.6.11-mm1).
> Rusty.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Fri, 4 Mar 2005, Rusty Russell wrote:
> On Wed, 2005-03-02 at 15:00 +0100, Adrian Bunk wrote:
> > Why doesn't an EXPORT_SYMBOL create a reference?
>
> It does: EXPORT_SYMBOL(x) drops the address of "x", including
> __attribute_used__, in the __ksymtab section.
Well, the problem is that this is still an internal reference in the same
object file. So ld looks into the lib .a archive, determines that none of
the symbols in that object file are needed to resolve a reference and
drops the entire .o file. Doing so, it drops the __ksymtab section as
well, which otherwise would be used by the kernel to look up that symbol.
So it drops the reference and the referencee ;), which is normally fine --
no unresolved symbols occur. Unfortunately, the kernel really needs to
know the contents of the __ksymtab sections to correctly export those
symbols, but it doesn't reference it in any explicit way.
I don't think there's an easy fix, except for not putting such objects
into an archive/lib, but to link them directly.
--Kai
On Fri, Mar 04, 2005 at 07:56:38PM +0100, Adrian Bunk wrote:
> On Fri, Mar 04, 2005 at 09:23:17PM +1100, Rusty Russell wrote:
> > On Wed, 2005-03-02 at 15:00 +0100, Adrian Bunk wrote:
> > > Why doesn't an EXPORT_SYMBOL create a reference?
> >
> > It does: EXPORT_SYMBOL(x) drops the address of "x", including
> > __attribute_used__, in the __ksymtab section.
> >
> > However, if CONFIG_MODULES=n, it does nothing: perhaps that is what you
> > are seeing.
>
> That's not the problem.
>
> And it has nothing to do with any gcc 4.0 issues mentioned in this
> thread - I saw this problem with gcc 3.3 .
>
> Try the attached .config in 2.6.11-rc4-mm1 (not in 2.6.11-mm1).
This time with the attachment. ;-)
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Fri, Mar 04, 2005 at 02:11:13PM -0500, Kai Germaschewski wrote:
> On Fri, 4 Mar 2005, Rusty Russell wrote:
>
> > On Wed, 2005-03-02 at 15:00 +0100, Adrian Bunk wrote:
> > > Why doesn't an EXPORT_SYMBOL create a reference?
> >
> > It does: EXPORT_SYMBOL(x) drops the address of "x", including
> > __attribute_used__, in the __ksymtab section.
>
> Well, the problem is that this is still an internal reference in the same
> object file. So ld looks into the lib .a archive, determines that none of
> the symbols in that object file are needed to resolve a reference and
> drops the entire .o file. Doing so, it drops the __ksymtab section as
> well, which otherwise would be used by the kernel to look up that symbol.
>
> So it drops the reference and the referencee ;), which is normally fine --
> no unresolved symbols occur. Unfortunately, the kernel really needs to
> know the contents of the __ksymtab sections to correctly export those
> symbols, but it doesn't reference it in any explicit way.
>
> I don't think there's an easy fix, except for not putting such objects
> into an archive/lib, but to link them directly.
Silly question:
What's the advantage of lib-y compared to obj-y?
> --Kai
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Fri, 4 Mar 2005, Adrian Bunk wrote:
> > [...] So ld looks into the lib .a archive, determines that none of
> > the symbols in that object file are needed to resolve a reference and
> > drops the entire .o file.
> Silly question:
> What's the advantage of lib-y compared to obj-y?
Basically exactly what I quoted above -- unused object files don't get
linked into the kernel image and don't take up (wasted) space. On the
other hand, files in obj-y get linked into the kernel unconditionally.
--Kai
On Sat, Mar 05, 2005 at 12:09:29AM -0500, Kai Germaschewski wrote:
> On Fri, 4 Mar 2005, Adrian Bunk wrote:
>
> > > [...] So ld looks into the lib .a archive, determines that none of
> > > the symbols in that object file are needed to resolve a reference and
> > > drops the entire .o file.
>
> > Silly question:
> > What's the advantage of lib-y compared to obj-y?
>
> Basically exactly what I quoted above -- unused object files don't get
> linked into the kernel image and don't take up (wasted) space. On the
> other hand, files in obj-y get linked into the kernel unconditionally.
And this can break as soon as the "unused" object files contains
EXPORT_SYMBOL's.
Is it really worth it doing it in this non-intuitive way?
I'd prefer an explicite dependency on a variable if you want to
compile library functions conditionally.
> --Kai
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Sat, 5 Mar 2005, Adrian Bunk wrote:
> And this can break as soon as the "unused" object files contains
> EXPORT_SYMBOL's.
>
> Is it really worth it doing it in this non-intuitive way?
I don't think it non-intuitive, it's how libraries work. However, as you
say, it is broken for files containing EXPORT_SYMBOL.
The obvious fix for this case is the one that akpm mentioned way earlier
in this thread, move parser.o into $(obj-y).
It should be rather easy to have the kernel build system warn you when you
compile library objects exporting symbols.
--Kai
On Sat, Mar 05, 2005 at 10:19:23AM -0500, Kai Germaschewski wrote:
> On Sat, 5 Mar 2005, Adrian Bunk wrote:
>
> > And this can break as soon as the "unused" object files contains
> > EXPORT_SYMBOL's.
> >
> > Is it really worth it doing it in this non-intuitive way?
>
> I don't think it non-intuitive, it's how libraries work. However, as you
> say, it is broken for files containing EXPORT_SYMBOL.
>
> The obvious fix for this case is the one that akpm mentioned way earlier
> in this thread, move parser.o into $(obj-y).
>
> It should be rather easy to have the kernel build system warn you when you
> compile library objects exporting symbols.
This warning sounds like a good plan (but it won't let many objects stay
inside lib-y).
> --Kai
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Sat, 5 Mar 2005, Adrian Bunk wrote:
> This warning sounds like a good plan (but it won't let many objects stay
> inside lib-y).
The patch is simple (except that the warning it throws looks rather ugly),
see appended.
However, I spoke too soon. There actually is a legitimate use for
EXPORT_SYMBOL() in a lib-y object, e.g. lib/dump_stack.c. This provides a
default implementation for dump_stack(). Most archs provide their own
implementation (and EXPORT_SYMBOL() it), and in this case we definitely
want the default version in lib to be thrown away, including its
EXPORT_SYMBOL. So the appended patch throws false positives and thus can
not be applied.
Still, many files in lib-y "should" be moved to obj-y. Then again, the
clear cases (e.g. ctype, vsnprintf) are getting used in the static kernel
image, so they get linked in anyway, moving them from lib-y to obj-y
doesn't make any difference whatsoever.
The interesting cases are more of the crc32 type -- some people may not
use this at all, so they want the space savings. Moving all of those into
obj-y unconditionally creates unnecessary bloat. Actually, crc32 already
did the right thing -- a config option. That would work for parser.o, too,
just make the filesystems which need it "select CONFIG_PARSER".
I think there are basically three cases of objects in lib-y:
o functions we clearly use anyway, e.g. vsprintf.o.
these should be always available, also for modules (pretty much every
module uses printk, right?)
So these should be in obj-y, however since they always get used in the
kernel, too, independent of the .config, in practice there's no
difference to them being in lib-y.
o "weak" implementations, which may be overwritten by a arch-specific
implementation.
These need to be in lib-y for this mechanism to work.
o Marginal cases like crc32.o, parser.o, bitmap.o
There are real world cases out there where these functions will never be
used, so just compiling them into the kernel because one day there may
be a module which wants to use them does cause some bloat. Making them
config options and have every module which needs them mention them in
Kconfig causes some bloat on the source side.
It's a trade-off. In my tree (current -bk), parser.o symbols are
referenced by procfs, i.e. 99.9% of all builds will pull it in anyway.
So putting it into obj-y is a good solution, IMO. (Do I hear the
embedded people cry?)
I guess in -mm this changed, which may justify going to CONFIG_PARSER
(along the lines of CONFIG_CRC32) way. Then again, .text of
parser.o is 0x373 bytes on my x86_64 system. Not a whole lot to
lose when it's compiled in unconditionally. (And it's used among others
by ext2 and ext3, so chances are, you need it anyway)
--Kai
===== include/linux/module.h 1.92 vs edited =====
--- 1.92/include/linux/module.h 2005-01-10 14:28:15 -05:00
+++ edited/include/linux/module.h 2005-03-05 10:49:05 -05:00
@@ -200,10 +200,18 @@
= { (unsigned long)&sym, __kstrtab_##sym }
#define EXPORT_SYMBOL(sym) \
+ __EXPORT_SYMBOL_WARN \
__EXPORT_SYMBOL(sym, "")
#define EXPORT_SYMBOL_GPL(sym) \
+ __EXPORT_SYMBOL_WARN \
__EXPORT_SYMBOL(sym, "_gpl")
+
+#ifdef KBUILD_LIB
+#define __EXPORT_SYMBOL_WARN DO_NOT_USE_EXPORT_SYMBOL_IN_LIBRARY_FILES;
+#else
+#define __EXPORT_SYMBOL_WARN
+#endif
#endif
===== scripts/Makefile.build 1.53 vs edited =====
--- 1.53/scripts/Makefile.build 2004-12-28 18:15:17 -05:00
+++ edited/scripts/Makefile.build 2005-03-05 10:34:44 -05:00
@@ -105,6 +105,8 @@
$(real-objs-m:.o=.s) : modkern_cflags := $(CFLAGS_MODULE)
$(real-objs-m:.o=.lst): modkern_cflags := $(CFLAGS_MODULE)
+$(lib-y) : lib_cflags := -DKBUILD_LIB
+
$(real-objs-m) : quiet_modtag := [M]
$(real-objs-m:.o=.i) : quiet_modtag := [M]
$(real-objs-m:.o=.s) : quiet_modtag := [M]
===== scripts/Makefile.lib 1.27 vs edited =====
--- 1.27/scripts/Makefile.lib 2004-10-26 18:06:46 -04:00
+++ edited/scripts/Makefile.lib 2005-03-05 10:33:38 -05:00
@@ -126,7 +126,7 @@
endif
c_flags = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(CPPFLAGS) \
- $(__c_flags) $(modkern_cflags) \
+ $(__c_flags) $(modkern_cflags) $(lib_cflags) \
$(basename_flags) $(modname_flags)
a_flags = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(CPPFLAGS) \
On Sat, Mar 05, 2005 at 11:36:23AM -0500, Kai Germaschewski wrote:
> On Sat, 5 Mar 2005, Adrian Bunk wrote:
>
> > This warning sounds like a good plan (but it won't let many objects stay
> > inside lib-y).
>
> The patch is simple (except that the warning it throws looks rather ugly),
> see appended.
>
> However, I spoke too soon. There actually is a legitimate use for
> EXPORT_SYMBOL() in a lib-y object, e.g. lib/dump_stack.c. This provides a
> default implementation for dump_stack(). Most archs provide their own
> implementation (and EXPORT_SYMBOL() it), and in this case we definitely
> want the default version in lib to be thrown away, including its
> EXPORT_SYMBOL. So the appended patch throws false positives and thus can
> not be applied.
That's usually solved through #define's (see e.g. lib/extable.c).
> Still, many files in lib-y "should" be moved to obj-y. Then again, the
> clear cases (e.g. ctype, vsnprintf) are getting used in the static kernel
> image, so they get linked in anyway, moving them from lib-y to obj-y
> doesn't make any difference whatsoever.
>
> The interesting cases are more of the crc32 type -- some people may not
> use this at all, so they want the space savings. Moving all of those into
> obj-y unconditionally creates unnecessary bloat. Actually, crc32 already
> did the right thing -- a config option. That would work for parser.o, too,
> just make the filesystems which need it "select CONFIG_PARSER".
It's used by many filesystems plus some optional part of the USB code.
Basically, there are two choices:
- always include a function
- include a function only if required
The second one is possible, but object files are the wrong granularity -
why should it pull the whole parser.c if only match_strdup was required?
You have all possibilities with #define's.
> I think there are basically three cases of objects in lib-y:
>
> o functions we clearly use anyway, e.g. vsprintf.o.
> these should be always available, also for modules (pretty much every
> module uses printk, right?)
> So these should be in obj-y, however since they always get used in the
> kernel, too, independent of the .config, in practice there's no
> difference to them being in lib-y.
Agreed.
> o "weak" implementations, which may be overwritten by a arch-specific
> implementation.
> These need to be in lib-y for this mechanism to work.
This doesn't work if the object file also contains other code.
> o Marginal cases like crc32.o, parser.o, bitmap.o
> There are real world cases out there where these functions will never be
> used, so just compiling them into the kernel because one day there may
> be a module which wants to use them does cause some bloat. Making them
> config options and have every module which needs them mention them in
> Kconfig causes some bloat on the source side.
Can you send a .config where bitmap.o isn't used?
> It's a trade-off. In my tree (current -bk), parser.o symbols are
> referenced by procfs, i.e. 99.9% of all builds will pull it in anyway.
> So putting it into obj-y is a good solution, IMO. (Do I hear the
> embedded people cry?)
> I guess in -mm this changed, which may justify going to CONFIG_PARSER
> (along the lines of CONFIG_CRC32) way. Then again, .text of
> parser.o is 0x373 bytes on my x86_64 system. Not a whole lot to
> lose when it's compiled in unconditionally. (And it's used among others
> by ext2 and ext3, so chances are, you need it anyway)
As above:
If you care about code size, CONFIG_PARSER gives the wrong granularity.
My general impression is:
Everything lib-y does can be done with obj- and #define's.
And this way, it's done explicit.
I'm not really happy with tricks like compiling two versions of
dump_stack() and the linker somehow discards the right one.
> --Kai
>...
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
> That's usually solved through #define's (see e.g. lib/extable.c).
Well, you can obviously solve pretty much everything with #define's, but
it's usually also the ugliest solution.
>From my point of view, the preferences for solving issues like the
extable.c one are:
o Do it automatically. If the architectecture defines its own version, use
that one -- otherwise use the default.
o Take care of it by configuration options.
Let the arch have CONFIG_GENERIC_EXTABLE_SORT (or not), and use that to
determine whether to compile / link sort_extable()
o Use a #define / #ifdef in the source file to conditionally compile
things.
Having a config option has the advantage that one can do
obj-$(CONFIG_GENERIC_EXTABLE_SORT) += extable_sort.o
which leaves the source code free of ugly #ifdef's. Obviously that only
works if extable.c is split into extable_sort.o and extable_search.o. If
one goes that step (fine IMO), one can however just add these files to
lib-y, i.e. use the first solution - everything happens automatically, no
need for ARCH_ defines, no need for new CONFIG options.
> It's used by many filesystems plus some optional part of the USB code.
>
> Basically, there are two choices:
> - always include a function
> - include a function only if required
>
> The second one is possible, but object files are the wrong granularity -
> why should it pull the whole parser.c if only match_strdup was required?
Yes, object files are not necessarily the right granularity -- in fact,
traditionally libraries are composed of object files which pretty much
follow a "one function per file" principle, to get this right.
However, two cases should be distinguished:
o providing a default implementation. Obviously, this one needs separate
files for separately needed units (like the extable.c example above)
o providing a library functionality. Grouping multiple functions together
isn't necessarily wrong, it just may cause slight inefficencies (pulling
in unneeded code). I really don't think we want to go to one function
per file but rather leave things grouped as they currently are. If
someone needs match_strdup, they'll pull in all of parser.o.
> You have all possibilities with #define's.
Yes, but also all the ugliness. There's a trade-off where the optimal
smallest binary kernel image comes with a bloated, unreadable, full of
'#ifdef' kernel source. Noone wants that. If you can optimize the binary
kernel image in some automated way with little impact on the source code,
that's fine. Otherwise, you'll give up a little space savings for easier
maintainability.
> If you care about code size, CONFIG_PARSER gives the wrong granularity.
Going more fine-grained is out of the question, IMO. If anything, going
less fine-grained, i.e. include all of parser.o unconditionally is the way
to go here. Currently, the only more fine-grained way would be to have
ext2 in KConfig CONFIG_MATCH_INT, CONFIG_MATCH_TOKEN. FAT would define
CONFIG_MATCH_INT, CONFIG_MATCH_TOKEN, CONFIG_MATCH_OCTAL, etc. That's
insanity.
> Everything lib-y does can be done with obj- and #define's.
> And this way, it's done explicit.
That's true. But more often than not, we don't care about explicitness,
we care about cleanliness and readability. The ugliness is hidden
somewhere, in includes, in Kconfig, in the build system. "module_init()"
is very non-explicit, it does completely different things depending on
whether a file is compiled into a module or the kernel. But we sure prefer
the cleanliness of module_init() over having #ifdef's in each module which
explicitly what happens.
As I said it's all a trade-off, and it has much to do with taste. Code
looking clean is important. However, hiding too much and jumping through
hoops just so that something looks clean while all the magic happens
somewhere deep inside unbeknowst to all but few gurus isn't right, either.
This discussion doesn't really have much to do with the original issue
anymore. Move parser.o to obj-y and be done with it -- in reality everyone
needs it, anyway. EXPORT_SYMBOL() sometimes and kinda unpredictably not
working in lib-y is tricky. But it produces obvious errors, unresolved
symbols, not obscure un-debuggable bugs.
--Kai
On Sat, Mar 05, 2005 at 10:19:23AM -0500, Kai Germaschewski wrote:
> On Sat, 5 Mar 2005, Adrian Bunk wrote:
>
> > And this can break as soon as the "unused" object files contains
> > EXPORT_SYMBOL's.
> >
> > Is it really worth it doing it in this non-intuitive way?
>
> I don't think it non-intuitive, it's how libraries work. However, as you
> say, it is broken for files containing EXPORT_SYMBOL.
>
> The obvious fix for this case is the one that akpm mentioned way earlier
> in this thread, move parser.o into $(obj-y).
>
> It should be rather easy to have the kernel build system warn you when you
> compile library objects exporting symbols.
Or rather get rid of librarz objects completely. We manage to have explicit
depencies for 99% of our needs, do we really need a special cases that breaks
for most of it's current users?
On Sat, Mar 05, 2005 at 11:36:23AM -0500, Kai Germaschewski wrote:
> However, I spoke too soon. There actually is a legitimate use for
> EXPORT_SYMBOL() in a lib-y object, e.g. lib/dump_stack.c. This provides a
> default implementation for dump_stack(). Most archs provide their own
> implementation (and EXPORT_SYMBOL() it), and in this case we definitely
> want the default version in lib to be thrown away, including its
> EXPORT_SYMBOL. So the appended patch throws false positives and thus can
> not be applied.
.. and should be replaced by CONFIG_GENERIC_DUMP_STACK or
__HAVE_ARCH_DUMP_STACK or something similar