[lkml]   [2008]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subjectkbuild: improved Section mismatch detection
I have spent the last week (the time I can afford to
Linux stuff anyway) to improve the Section mismatch
warnings detected by modpost.

The problem until now has been that the Section
mismatch warnings were dependent on the actual
In the default configuration with HOTPLUG enbaled most
of the remaining Section mismatch warnings were not
seen and thus many of us thought that everything was great.

Adrian reminded us that KCFLAGS=-fno-inline told
another story with more than 100 Section mismatch
warnings on 64 bit x86 with an allyesconfig build.

As this was not acceptable I set out to make it
less configuration dependent. To do so I quikly
relaised that modpost had to be prepared before this
was a feasible thing to implment.

This serie of patches is:

1) kbuild: fix so modpost can now check any .o file
2) kbuild: try harder to find symbol names in modpost
3) kbuild: code refactoring in modpost
4) kbuild: introduce blacklisting in modpost
5) kbuild: check section names consistently in modpost
6) all archs: consolidate init and exit sections in
7) compiler.h: introduce __section()
8) Use separate sections for __dev/__cpu/__mem code/data

Patch 6) makse a set of trivial changes in all arch files
and the reason why I copid linux-arch on this mail.

Patch 4) is a major change in modpost where we no longer try to
find all the good guys but instead look for the bad combinations.
This should result in a lot less false warnings and for example got
rid of an irritating warning on sparc64.

Patch 2) is important - previously modpost failed to find the
correct symbol based on address lookup because it wanted an exact
match. Allowing up to 20 bytes offset we now locate almost all
symbols and the warnings are much easier to fix.

Randy and Adrian among others have done a great job fixing
many Section mismatch warnngs over the last month.
But frankly much more people should do this and I can see people
ignoring the warnings.

Therefore the plan is to turn the warnings into hard build errors
at -rc1 time.
This should force people to actually fix the warnings they introduce.

But to do so we need the warnings we have today gettign fixed and
the new improved modpost should help you here.
To further help the plans are to:
- add a config option to enable -fno-inline (or a similar option)
- make the warnings from modpost more descriptive but longer
- maybe to spend a few hours to fix some of the obvious candidates
Less than half an hour for each warning for the trivial cases
- Maybe start using __INIT and friends in assembler code
xen had two bugs in this area recently for example.

It has been questions if it is worth the effort to fix these warnings.
Randy just fixed three oops candidates - do anyone need more facts?

And the cpu code looks rather fragile in the dead/removed CPU cases.
I see several references that will oops and is easy to fix.


 \ /
  Last update: 2008-01-20 21:07    [W:0.094 / U:0.448 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site