[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111019163351.GJ15908@one.firstfloor.org>
Date: Wed, 19 Oct 2011 18:33:51 +0200
From: Andi Kleen <andi@...stfloor.org>
To: James Bottomley <James.Bottomley@...senPartnership.com>
Cc: Andi Kleen <andi@...stfloor.org>,
Stephen Rothwell <sfr@...b.auug.org.au>,
linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: Please include const-sections into linux-next
> I think I've already said 3 times that I think it's some kind of
> toolchain bug. The problem is it's likely in all the non-x86
> toolchains.
Not convinced it's everywhere. Just need to track it down.
>
> > > linker script? Linker scripts seem to be much better tested.
> >
> > The linker script just declares the order of the section.
> > The attributes are a union of what the compiler declares.
> > To dump them I just use objdump --section-headers or
> > readelf -a usually.
>
> OK, look at it another way: why do we need the type annotations? I
> think it's only for section conflict checking, right? If the compiler
> gets it wrong anyway, why not just dump all the type annotations, then
> it should have no type conflicts (spurious or otherwise) to complain
> about. We already have link time section checking scripts (they're the
> useless ones that complain about section mismatches in dev annoations)
> so why not put them to work to make up for compiler deficiencies?
You mean removing all the init sections stuff? I think it has been proposed
in the past, but it's a couple of hundred KB of memory usually.
Would you accept that for PA-RISC?
If you have init sections you need to annotate them correctly because
a section is defined by its rwx attributes plus name and both need
to match. We didn't always check this, so there was some bitrot,
but it ultimatively has to be correct.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists