> However, storing the information in a separate ELF section doesn't solve
> this, unless you actually have GCC generate the hash code. (If you store
> the hash code in slab.ver, you'd still have the same problem.) In fact,
> if you have GCC generate the hash code, it'd solve this problem whether
> the hash code is stored as part of the symbol name, or in a separate ELF
> section.
So GCC must generate the hash code. OK.
> The problem with this, of course, is that we'd be dependent on a
> specially hacked version of GCC --- unless you can get these
> changes into the FSF's GCC mainline, which can sometimes be a trick.
> (Just ask the egcc people! :-)
If the egcs people have any trouble, we _will_ be dependent on a
specially hacked version of GCC anyway. That is not a problem,
since normal gcc development is too slow anyway.
Can anybody imagine official gcc supporting ia64 before
the unix clock runs out? I don't see gcc 2.8 yet.
If the kernel needs a special gcc for module versions, then that
is simply what it needs. Standard gcc could still compile a kernel
without modules.