Re: gold input section handling

[David Miller <davem at davemloft dot net>]

From: Andi Kleen <andi@firstfloor.org>
Date: Mon, 14 Apr 2008 21:41:38 +0200

> Also there is always the issue that even if it was fixed at the kernel
> level, would you really want to prevent users from compiling older
> kernels?

Right.  I think gold not being able to build existing software
is going to be a major blocker for adoption.

FWIW, here is what is happening, we mark data of all types with
a section specifier:

#define __devinitdata    __section(.devinit.data)

in my testcase a file under drivers/ide/ does:

static const struct ide_port_info ali15x3_chipset __devinitdata = {
 ...
};

and thus the section ends up with just ALLOC being set in the
flags.

Other objects define non-const data into that section, thus ending up
with ALLOC and WRITE being set.

We try to link these together and that's where the problem comes
from.

I think what the kernel is doing is quite reasonable.  It just
wants to put various kinds of data into a section of a certain
name.  I don't see any reason why a programmer should hae to
know about "compatible section flags", and thus be required to
put const things into a section seperate from the one where
non-const ones go.