[ccache] Re: [REGRESSION] Recent change to kernel spikes out ccache/distcc

[Al Viro]

On Wed, Jan 07, 2009 at 08:49:18AM +0000, Jan Beulich wrote:
> >>> Al Viro <viro at ZenIV.linux.org.uk> 07.01.09 06:10 >>>
> >On Tue, Jan 06, 2009 at 10:15:26AM -0500, Theodore Ts'o wrote:
> >> Or, if that's too complicated, maybe it would be worthwhile to have
> >> kbuild create its own specialized ccache system?  Note that the last two
> >> solutions rule out using distcc, unless we can encapsulate the build
> >> process from a series of Makefile macros to a shell or C program, which
> >> could then be injected to the remote host system to be executed by
> >> distcc.  One value of doing that is the CRC or MD5 of the shell script
> >> could be used as the version tag for the cache system.
> >
> >Ho-hum...  Could somebody explain why the hell had we switched to this
> >"intermediate .s" approach, anyway?  It's not as if we couldn't run
> >objcopy after what we used to do...
> 
> Because objcopy wouldn't remove the __crc_* symbols the way the
> object files were generated previously. I explored all possibilities I could
> think of, with that two step process being the last, but the only one that
> had the intended effect. In the end I queried the binutils list, and got
> confirmation that there's no (existing) way to get rid of symbols used in
> relocations in an already existing object file without corrupting it.

I do not understand two things.
	a) WTF would we care about ones in vmlinux, when kallsyms drops the
absolute ones anyway?
	b) is there any reason why we can't copy symbol table out of module
ourselves (instead of setting SHF_ALLOC on it) and trim the crap out of
it?  Note that __crc_... is not the only junk in there - you don't need
(or want) to keep the things like undefs for /proc/kallsyms purposes.
And modules *using* an exported symbol are more common that modules exporting
one...  Why not copy it at add_kallsyms() time, skipping the junk we don't
want anyway?