Thread (26 messages) 26 messages, 4 authors, 2011-10-19

Re: Please include const-sections into linux-next

From: James Bottomley <James.Bottomley@HansenPartnership.com>
Date: 2011-10-19 16:21:26
Also in: lkml

On Wed, 2011-10-19 at 18:15 +0200, Andi Kleen wrote:
On Wed, Oct 19, 2011 at 10:54:23AM -0500, James Bottomley wrote:
quoted
quoted
One alternative to track it down would be to apply the attached
patch to the gcc, then gcc would print it out.
I think the basic problem that excites the toolchain somehow is
sectional annotations.  Can't we just dump them and do it all in a
We already use these annotations all over. Just currently they mess up
the 'r' and 'w' bits on the sections because a few (not the majority)
of declarations mismatch the ro vs rw sections.  My patchkit was just trying
to fix up those that were wrong

So you should be already using them.

Just need to find out what triggers your toolchain with these changes.
I suspect it's some kind of toolchain bug.
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.
quoted
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?

James
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help