Re: Undefined symbols in 2.6.11-rc5-mm1

[Adrian Bunk]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/