> What goals are you proposing to solve by going using more the ELF
> features? The symbols are ugly, true, but is there anything else that
> you want to solve by doing this?
I want separate compilation.
Right now, if drivers/net/foo.o has an external symbol for kmalloc, it
depends on include/modules/slab.ver, which is generated from mm/slab.c.
So changes in mm/slab.c cause all modules to be rebuilt because type
information from mm/slab.c goes into all module files.
Rules.make is a tangled mess to handle this.
> Storing the type information in a seperate ELF section is cleaner,
> granted, but way ELF stores type information for use with debugging is
> (a) very large, and (b) produces incomparable information if two object
> files #include a different set of system header files, or #include them
> in a different order.
This is true. I don't want to use 'gcc -g' to produce the type
information for these reasons. I think the existing 'genksyms' or
something like it provides adequate protection: one hash code per
symbol.
Michael Chastain
<mailto:mec@shout.net>
"love without fear"