Re: Undefined symbols in 2.6.11-rc5-mm1
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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), __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) \
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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) \
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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 # # Automatically generated make config: don't edit # Linux kernel version: 2.6.11-rc4-mm1 # Fri Mar 4 19:41:08 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_BASE_FULL=y CONFIG_BASE_SMALL=0 CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_USE_3DNOW=y # CONFIG_HPET_TIMER is not set # CONFIG_SMP is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=m # CONFIG_X86_MCE_P4THERMAL is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # # Firmware Drivers # # CONFIG_EDD is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_HAVE_DEC_LOCK=y CONFIG_REGPARM=y CONFIG_SECCOMP=y # # Performance-monitoring counters support # # CONFIG_PERFCTR is not set CONFIG_PHYSICAL_START=0x10 # CONFIG_KEXEC is not set # # Power management options (ACPI, APM) # CONFIG_PM=y # CONFIG_PM_DEBUG is not set # CONFIG_SOFTWARE_SUSPEND is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y # CONFIG_ACPI_AC is not set # CONFIG_ACPI_BATTERY is not set CONFIG_ACPI_BUTTON=y # CONFIG_ACPI_VIDEO is not set CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_IBM is not set # CONFIG_ACPI_TOSHIBA is not set # CONFIG_ACPI_PCC is not set # CONFIG_ACPI_SONY is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y # CONFIG_ACPI_CONTAINER is not set
Re: Undefined symbols in 2.6.11-rc5-mm1
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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 # # Automatically generated make config: don't edit # Linux kernel version: 2.6.11-rc4-mm1 # Fri Mar 4 19:41:08 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y # # General setup # CONFIG_LOCALVERSION= CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_BASE_FULL=y CONFIG_BASE_SMALL=0 CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_USE_3DNOW=y # CONFIG_HPET_TIMER is not set # CONFIG_SMP is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=m # CONFIG_X86_MCE_P4THERMAL is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # # Firmware Drivers # # CONFIG_EDD is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_HAVE_DEC_LOCK=y CONFIG_REGPARM=y CONFIG_SECCOMP=y # # Performance-monitoring counters support # # CONFIG_PERFCTR is not set CONFIG_PHYSICAL_START=0x10 # CONFIG_KEXEC is not set # # Power management options (ACPI, APM) # CONFIG_PM=y # CONFIG_PM_DEBUG is not set # CONFIG_SOFTWARE_SUSPEND is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y # CONFIG_ACPI_AC is not set # CONFIG_ACPI_BATTERY is not set CONFIG_ACPI_BUTTON=y # CONFIG_ACPI_VIDEO is not set CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_IBM is not set # CONFIG_ACPI_TOSHIBA is not set # CONFIG_ACPI_PCC is not set # CONFIG_ACPI_SONY is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y # CONFIG_ACPI_CONTAINER is not set # # APM (Advanced Power
Re: Undefined symbols in 2.6.11-rc5-mm1
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
[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?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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?
pgpV6dFG9hhnl.pgp
Description: PGP signature
Re: Undefined symbols in 2.6.11-rc5-mm1
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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. config-2.6.11-rc5-mm1 Description: Binary data
Re: Undefined symbols in 2.6.11-rc5-mm1
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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. config-2.6.11-rc5-mm1 Description: Binary data
Re: Undefined symbols in 2.6.11-rc5-mm1
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Undefined symbols in 2.6.11-rc5-mm1
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?
pgpV6dFG9hhnl.pgp
Description: PGP signature
Re: Undefined symbols in 2.6.11-rc5-mm1
[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?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
