Please include const-sections into linux-next

Please include const-sections into linux-next

[Andi Kleen]

Stephen,

Please include 
git://github.com/andikleen/linux-misc.git const-sections
in linux-next. This has a tree sweep to fix all kind of constant 
section issues.

I intend to send Linus a pull request next cycle and would like 
to get some testing in next first.

I got various acks last time it was posted and added them all.
In general it falls more in the "trivial" category, but it's 
rather large and all over so I may have made a mistake.

Thanks,

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

Re: Please include const-sections into linux-next

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1421 bytes --]

Hi Andi,

On Fri, 14 Oct 2011 01:38:18 +0200 Andi Kleen <andi@firstfloor.org> wrote:
>
> Please include 
> git://github.com/andikleen/linux-misc.git const-sections
> in linux-next. This has a tree sweep to fix all kind of constant 
> section issues.
> 
> I intend to send Linus a pull request next cycle and would like 
> to get some testing in next first.

You picked a bad time unfortunately.  Today will amost certainly be the
last linux-next tree before the merge window opens (since I will be on
vacation until kernel summit) so if it breaks the tree, it will impact on
others testing (and there won't be a followup tree to correct the problem).

Also, the commit messages are still very terse (as a few people pointed
out) and I have seen no response to Thomas' remarks either.

> I got various acks last time it was posted and added them all.
> In general it falls more in the "trivial" category, but it's 
> rather large and all over so I may have made a mistake.

It really isn't trivial because we have had various problems with init
and const in the past with various toolchains (and even different
problems on different architectures with the "same" toolchain).

Linus or Andrew may still want to take these, but I don't think I can add
it to linux-next right now, sorry.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: Please include const-sections into linux-next

[James Bottomley]

On Fri, 2011-10-14 at 01:38 +0200, Andi Kleen wrote:
> Stephen,
> 
> Please include 
> git://github.com/andikleen/linux-misc.git const-sections
> in linux-next. This has a tree sweep to fix all kind of constant 
> section issues.
> 
> I intend to send Linus a pull request next cycle and would like 
> to get some testing in next first.
> 
> I got various acks last time it was posted and added them all.
> In general it falls more in the "trivial" category, but it's 
> rather large and all over so I may have made a mistake.

It's not incredibly trivial: it causes a compile failure on parisc:

mm/percpu.c:1372: error: __setup_str_percpu_alloc_setup causes a section
type conflict
make[1]: *** [mm/percpu.o] Error 1

I have no idea why, though.

James

[patch] parisc, iommu: add missing include for prefetchw()

[David Rientjes]

prefetchw() requires it to be defined by linux/prefetch.h, or it results
in a compile error:

In file included from drivers/parisc/sba_iommu.c:916:0:
drivers/parisc/iommu-helpers.h: In function 'iommu_fill_pdir':
drivers/parisc/iommu-helpers.h:62:4: error: implicit declaration of function 'prefetchw'

Include linux/prefetch.h.

Signed-off-by: David Rientjes <rientjes@google.com>
---
 drivers/parisc/iommu-helpers.h |    2 ++
 1 files changed, 2 insertions(+)

diff --git a/drivers/parisc/iommu-helpers.h b/drivers/parisc/iommu-helpers.h
--- a/drivers/parisc/iommu-helpers.h
+++ b/drivers/parisc/iommu-helpers.h
@@ -1,3 +1,5 @@
+#include <linux/prefetch.h>
+
 /**
  * iommu_fill_pdir - Insert coalesced scatter/gather chunks into the I/O Pdir.
  * @ioc: The I/O Controller.

[patch] parisc, iommu: add missing include for prefetchw()

[David Rientjes]

prefetchw() requires it to be defined by linux/prefetch.h, or it results
in a compile error:

In file included from drivers/parisc/sba_iommu.c:916:0:
drivers/parisc/iommu-helpers.h: In function 'iommu_fill_pdir':
drivers/parisc/iommu-helpers.h:62:4: error: implicit declaration of function 'prefetchw'

Include linux/prefetch.h.

Signed-off-by: David Rientjes <rientjes@google.com>
---
 drivers/parisc/iommu-helpers.h |    2 ++
 1 files changed, 2 insertions(+)

diff --git a/drivers/parisc/iommu-helpers.h b/drivers/parisc/iommu-helpers.h
--- a/drivers/parisc/iommu-helpers.h
+++ b/drivers/parisc/iommu-helpers.h
@@ -1,3 +1,5 @@
+#include <linux/prefetch.h>
+
 /**
  * iommu_fill_pdir - Insert coalesced scatter/gather chunks into the I/O Pdir.
  * @ioc: The I/O Controller.

Re: [patch] parisc, iommu: add missing include for prefetchw()

[James Bottomley]

On Sat, 2011-10-15 at 15:38 -0700, David Rientjes wrote:
> prefetchw() requires it to be defined by linux/prefetch.h, or it results
> in a compile error:
> 
> In file included from drivers/parisc/sba_iommu.c:916:0:
> drivers/parisc/iommu-helpers.h: In function 'iommu_fill_pdir':
> drivers/parisc/iommu-helpers.h:62:4: error: implicit declaration of function 'prefetchw'
> 
> Include linux/prefetch.h.

This isn't physically possible on the parisc platform: prefetch.h is
included by processor.h which, amongst other things, goes into
spinlock.h which is above this file in sba_iommu.c

How did you try to compile this file?

James

Re: [patch] parisc, iommu: add missing include for prefetchw()

[James Bottomley]

On Sat, 2011-10-15 at 15:38 -0700, David Rientjes wrote:
> prefetchw() requires it to be defined by linux/prefetch.h, or it results
> in a compile error:
> 
> In file included from drivers/parisc/sba_iommu.c:916:0:
> drivers/parisc/iommu-helpers.h: In function 'iommu_fill_pdir':
> drivers/parisc/iommu-helpers.h:62:4: error: implicit declaration of function 'prefetchw'
> 
> Include linux/prefetch.h.

This isn't physically possible on the parisc platform: prefetch.h is
included by processor.h which, amongst other things, goes into
spinlock.h which is above this file in sba_iommu.c

How did you try to compile this file?

James

Re: [patch] parisc, iommu: add missing include for prefetchw()

[David Rientjes]

On Sat, 15 Oct 2011, James Bottomley wrote:

> This isn't physically possible on the parisc platform: prefetch.h is
> included by processor.h which, amongst other things, goes into
> spinlock.h which is above this file in sba_iommu.c
> 

asm/prefetch.h is included in processor.h, not linux/prefetch.h.  Thus, 
it's undefined for CONFIG_PA20=n.

> How did you try to compile this file?
> 

make allyesconfig
make drivers/parisc/sba_iommu.o

Re: [patch] parisc, iommu: add missing include for prefetchw()

[David Rientjes]

On Sat, 15 Oct 2011, James Bottomley wrote:

> This isn't physically possible on the parisc platform: prefetch.h is
> included by processor.h which, amongst other things, goes into
> spinlock.h which is above this file in sba_iommu.c
> 

asm/prefetch.h is included in processor.h, not linux/prefetch.h.  Thus, 
it's undefined for CONFIG_PA20=n.

> How did you try to compile this file?
> 

make allyesconfig
make drivers/parisc/sba_iommu.o

Re: [patch] parisc, iommu: add missing include for prefetchw()

[James Bottomley]

On Sat, 2011-10-15 at 17:41 -0700, David Rientjes wrote:
> On Sat, 15 Oct 2011, James Bottomley wrote:
> 
> > This isn't physically possible on the parisc platform: prefetch.h is
> > included by processor.h which, amongst other things, goes into
> > spinlock.h which is above this file in sba_iommu.c
> > 
> 
> asm/prefetch.h is included in processor.h, not linux/prefetch.h.  Thus, 
> it's undefined for CONFIG_PA20=n.

sba_iommu isn't possible with CONFIG_PA20=n; it's a ZX1 or above
feature.

> > How did you try to compile this file?
> > 
> 
> make allyesconfig
> make drivers/parisc/sba_iommu.o


OK, so just take one of the standard configs ... I don't think anyone's
tried much randconfig testing over parisc, most of the configuration
lore is handed down from the mountain on stone tablets.

James

Re: [patch] parisc, iommu: add missing include for prefetchw()

[David Rientjes]

On Sat, 15 Oct 2011, James Bottomley wrote:

> > > How did you try to compile this file?
> > > 
> > 
> > make allyesconfig
> > make drivers/parisc/sba_iommu.o
> 
> OK, so just take one of the standard configs ... I don't think anyone's
> tried much randconfig testing over parisc, most of the configuration
> lore is handed down from the mountain on stone tablets.
> 

This isn't randconfig, it's allyesconfig, and this is the only compile 
error that I got while trying to reproduce your percpu.c compile failure.  
Everything else works fine.

Re: Please include const-sections into linux-next

[David Rientjes]

On Fri, 14 Oct 2011, James Bottomley wrote:

> It's not incredibly trivial: it causes a compile failure on parisc:
> 
> mm/percpu.c:1372: error: __setup_str_percpu_alloc_setup causes a section
> type conflict
> make[1]: *** [mm/percpu.o] Error 1
> 
> I have no idea why, though.
> 

Not sure why this would only happen on parisc, but I haven't looked at it 
closely.  It means something qualified with const is being defined in a 
section with other definitions that are not const, or vice versa.

For example:

	static int x __attribute__((__section__("foo"))) = 1;
	static const int y __attribute__((__section__("foo"))) = 2;

will result in the same error.  Since __setup_param() places 
__setup_str_percpu_alloc_setup in .init.rodata as const, it means 
something else has already been defined in .init.rodata without being 
qualified as such.

Re: Please include const-sections into linux-next

[James Bottomley]

On Sat, 2011-10-15 at 16:03 -0700, David Rientjes wrote:
> On Fri, 14 Oct 2011, James Bottomley wrote:
> 
> > It's not incredibly trivial: it causes a compile failure on parisc:
> > 
> > mm/percpu.c:1372: error: __setup_str_percpu_alloc_setup causes a section
> > type conflict
> > make[1]: *** [mm/percpu.o] Error 1
> > 
> > I have no idea why, though.
> > 
> 
> Not sure why this would only happen on parisc, but I haven't looked at it 
> closely.  It means something qualified with const is being defined in a 
> section with other definitions that are not const, or vice versa.

I think it's probably a compiler bug.  gcc isn't as adept with section
annotations as people think it is.  This tends to manifest in the
non-x86 toolchains because we tend to be using earlier versions.

James

Re: Please include const-sections into linux-next

[David Rientjes]

On Sat, 15 Oct 2011, James Bottomley wrote:

> I think it's probably a compiler bug.  gcc isn't as adept with section
> annotations as people think it is.  This tends to manifest in the
> non-x86 toolchains because we tend to be using earlier versions.
> 

It compiles fine with my cross-compiler using gcc-4.5.1.

Re: Please include const-sections into linux-next

[David Rientjes]

On Sat, 15 Oct 2011, James Bottomley wrote:

> I think it's probably a compiler bug.  gcc isn't as adept with section
> annotations as people think it is.  This tends to manifest in the
> non-x86 toolchains because we tend to be using earlier versions.
> 

It compiles fine with my cross-compiler using gcc-4.5.1.

Re: Please include const-sections into linux-next

[James Bottomley]

On Sat, 2011-10-15 at 17:53 -0700, David Rientjes wrote:
> On Sat, 15 Oct 2011, James Bottomley wrote:
> 
> > I think it's probably a compiler bug.  gcc isn't as adept with section
> > annotations as people think it is.  This tends to manifest in the
> > non-x86 toolchains because we tend to be using earlier versions.
> > 
> 
> It compiles fine with my cross-compiler using gcc-4.5.1.

So it's a native toolchain bug in gcc ... the point still stands:
there'll be tons of these throughout non x86 tool chains.  You can't
break every arch under the sun just for a dubious mark stuff const.

James

Re: Please include const-sections into linux-next

[Andi Kleen]

> I have no idea why, though.

Thanks for testing.

Yes it's hard to tell with plain gcc (before 4.7)
I have a special gcc patch to tell me the other symbol :)

Usually it's because some other symbol is wrong. In this 
case it must be in the same translation unit.

Can you please do

make mm/percpu.i 

on that build and send me the percpu.i in private email?

Thanks,
-Andi

Re: Please include const-sections into linux-next

[James Bottomley]

On Sun, 2011-10-16 at 05:35 +0200, Andi Kleen wrote:
> > I have no idea why, though.
> 
> Thanks for testing.
> 
> Yes it's hard to tell with plain gcc (before 4.7)
> I have a special gcc patch to tell me the other symbol :)
> 
> Usually it's because some other symbol is wrong. In this 
> case it must be in the same translation unit.
> 
> Can you please do
> 
> make mm/percpu.i 
> 
> on that build and send me the percpu.i in private email?

OK, so after fixing up that one, the next failure is:

drivers/net/fealnx.c:95: error: version causes a section type conflict
drivers/net/fealnx.c:1944: error: fealnx_pci_tbl causes a section type conflict

James

Re: Please include const-sections into linux-next

[Andi Kleen]

[-- Attachment #1: Type: text/plain, Size: 731 bytes --]

vate email?
>
> OK, so after fixing up that one, the next failure is:
>
> drivers/net/fealnx.c:95: error: version causes a section type conflict
> drivers/net/fealnx.c:1944: error: fealnx_pci_tbl causes a section type
> conflict

Hmm, this is weird (just like the other error)
I wonder if the pa-risc tool chain has some general problems with sections

On a successful build with the same config could you send me the output of

make drivers/net/fealnx.s
and
make drivers/net/fealnx.i

in the same config privately? From that I can see if there's something else
in init.rodata that does not match my i386 build.

One alternative to track it down would be to apply the attached
patch to the gcc, then gcc would print it out.

-Andi

[-- Attachment #2: section-conflict --]
[-- Type: application/octet-stream, Size: 1521 bytes --]

commit b74d9e7a4a76afe4fd769881525f89f89324be8c
Author: ak <ak@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Thu Jun 9 06:22:17 2011 +0000

    better warning for section conflict
    
    gcc/:
    
    2011-06-08  Andi Kleen  <ak@linux.intel.com>
    
    	* varasm.c (get_section): Print location of other conflict
    	for section conflicts.
    
    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@174836 138bc75d-0d04-0410-961f-82ee72b054a4

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 820bcbd..1c9fa02 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,10 @@
 2011-06-08  Andi Kleen  <ak@linux.intel.com>
 
+	* varasm.c (get_section): Print location of other conflict
+	for section conflicts.
+
+2011-06-08  Andi Kleen  <ak@linux.intel.com>
+
 	* config/i386/driver-i386.c (host_detect_local_cpu):
 	Add model 0x2d Intel CPU.
 
diff --git a/gcc/varasm.c b/gcc/varasm.c
index 3311c86..a0a0582 100644
--- a/gcc/varasm.c
+++ b/gcc/varasm.c
@@ -313,7 +313,11 @@ get_section (const char *name, unsigned int flags, tree decl)
 	  if (decl == 0)
 	    decl = sect->named.decl;
 	  gcc_assert (decl);
-	  error ("%+D causes a section type conflict", decl);
+	  error ("%+D causes a section type conflict with %D", 
+			decl, sect->named.decl);
+	  if (decl != sect->named.decl)
+            inform (DECL_SOURCE_LOCATION (sect->named.decl), 
+		    "%qD was declared here", sect->named.decl);
 	  /* Make sure we don't error about one section multiple times.  */
 	  sect->common.flags |= SECTION_OVERRIDE;
 	}

Re: Please include const-sections into linux-next

[James Bottomley]

On Sun, 2011-10-16 at 23:57 +0200, Andi Kleen wrote:
> vate email?
> >
> > OK, so after fixing up that one, the next failure is:
> >
> > drivers/net/fealnx.c:95: error: version causes a section type conflict
> > drivers/net/fealnx.c:1944: error: fealnx_pci_tbl causes a section type
> > conflict
> 
> Hmm, this is weird (just like the other error)
> I wonder if the pa-risc tool chain has some general problems with sections
> 
> On a successful build with the same config could you send me the output of
> 
> make drivers/net/fealnx.s
> and
> make drivers/net/fealnx.i

> in the same config privately? From that I can see if there's something else
> in init.rodata that does not match my i386 build.

Yes, I'll send under separate cover.

> 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
linker script?  Linker scripts seem to be much better tested.

James

Re: Please include const-sections into linux-next

[Andi Kleen]

On Wed, Oct 19, 2011 at 10:54:23AM -0500, James Bottomley wrote:
> 
> > 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.

> 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.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

Re: Please include const-sections into linux-next

[Andi Kleen]

On Wed, Oct 19, 2011 at 10:54:23AM -0500, James Bottomley wrote:
> 
> > 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.

> 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.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

Re: Please include const-sections into linux-next

[James Bottomley]

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:
> > 
> > > 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.

> > 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

Re: Please include const-sections into linux-next

[Andi Kleen]

> 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

Re: Please include const-sections into linux-next

[James Bottomley]

On Wed, 2011-10-19 at 18:33 +0200, Andi Kleen wrote:
> > 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.

We're talking at cross purposes. But it doesn't matter, the error
doesn't seem to be anything to do with type.  This simple patch is
what's causing it (I can apply it alone to the working tree) and get the
error.

What I can't see is why.

James

---
diff --git a/drivers/net/fealnx.c b/drivers/net/fealnx.c
index fa8677c..196356f 100644
--- a/drivers/net/fealnx.c
+++ b/drivers/net/fealnx.c
@@ -150,7 +150,7 @@ struct chip_info {
 	int flags;
 };
 
-static const struct chip_info skel_netdrv_tbl[] __devinitdata = {
+static const struct chip_info skel_netdrv_tbl[] __devinitconst = {
  	{ "100/10M Ethernet PCI Adapter",	HAS_MII_XCVR },
 	{ "100/10M Ethernet PCI Adapter",	HAS_CHIP_XCVR },
 	{ "1000/100/10M Ethernet PCI Adapter",	HAS_MII_XCVR },

Re: Please include const-sections into linux-next

[Andi Kleen]

On Wed, Oct 19, 2011 at 01:55:57PM -0500, James Bottomley wrote:
> On Wed, 2011-10-19 at 18:33 +0200, Andi Kleen wrote:
> > > 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.
> 
> We're talking at cross purposes. But it doesn't matter, the error
> doesn't seem to be anything to do with type.  This simple patch is
> what's causing it (I can apply it alone to the working tree) and get the
> error.
> 
> What I can't see is why.

For some reason your compiler sets the const section read/write:

.section        .devinit.data,"aw",@progbits     <---- writable
        .align 8
        .type   skel_netdrv_tbl, @object
        .size   skel_netdrv_tbl, 48
skel_netdrv_tbl:
; chip_name:
        .dword  .LC56

while my x86 toolchain sets it to read only

        .string "1000/100/10M Ethernet PCI Adapter"
        .section        .devinit.data,"a",@progbits   <---- not writable
        .align 16
        .type   skel_netdrv_tbl, @object
        .size   skel_netdrv_tbl, 48
skel_netdrv_tbl:
# chip_name:
        .quad   .LC32
# flags:
        .long   0
        .zero   4

If you check a few other const symbols with own
section are they all also writable?

-andi

Re: Please include const-sections into linux-next

[James Bottomley]

On Wed, 2011-10-19 at 21:05 +0200, Andi Kleen wrote:
> On Wed, Oct 19, 2011 at 01:55:57PM -0500, James Bottomley wrote:
> > On Wed, 2011-10-19 at 18:33 +0200, Andi Kleen wrote:
> > > > 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.
> > 
> > We're talking at cross purposes. But it doesn't matter, the error
> > doesn't seem to be anything to do with type.  This simple patch is
> > what's causing it (I can apply it alone to the working tree) and get the
> > error.
> > 
> > What I can't see is why.
> 
> For some reason your compiler sets the const section read/write:
> 
> .section        .devinit.data,"aw",@progbits     <---- writable
>         .align 8
>         .type   skel_netdrv_tbl, @object
>         .size   skel_netdrv_tbl, 48
> skel_netdrv_tbl:
> ; chip_name:
>         .dword  .LC56
> 
> while my x86 toolchain sets it to read only
> 
>         .string "1000/100/10M Ethernet PCI Adapter"
>         .section        .devinit.data,"a",@progbits   <---- not writable
>         .align 16
>         .type   skel_netdrv_tbl, @object
>         .size   skel_netdrv_tbl, 48

So most of our const stuff is "a" not "aw".  However, this particular
list is a list of strings ... this is probably something to do with
writeable strings?

James

Re: Please include const-sections into linux-next

[James Bottomley]

On Wed, 2011-10-19 at 15:04 -0500, James Bottomley wrote:
> this is probably something to do with writeable strings?

Bingo!  If I add -fno-writeable-strings to the compiler directives, it
works.

James

Re: Please include const-sections into linux-next

[Andi Kleen]

> On Wed, 2011-10-19 at 15:04 -0500, James Bottomley wrote:
>> this is probably something to do with writeable strings?
>
> Bingo!  If I add -fno-writeable-strings to the compiler directives, it
> works.

Cool thanks. I assume the resulting kernel works.

This means the pa compiler defaults to -fwritable-strings? Odd.

Are you handling that or should I add a patch to the tree?

-Andi

Re: Please include const-sections into linux-next

[James Bottomley]

On Wed, 2011-10-19 at 22:11 +0200, Andi Kleen wrote:
> > On Wed, 2011-10-19 at 15:04 -0500, James Bottomley wrote:
> >> this is probably something to do with writeable strings?
> >
> > Bingo!  If I add -fno-writeable-strings to the compiler directives, it
> > works.
> 
> Cool thanks. I assume the resulting kernel works.
> 
> This means the pa compiler defaults to -fwritable-strings? Odd.
> 
> Are you handling that or should I add a patch to the tree?

Actually, no, sorry ... its a false positive -fno-writeable-strings
actually produces an error which was lost in all the debug output (it's
at the top) so it wasn't working; I only thought it was.

James

Re: Please include const-sections into linux-next

[Andi Kleen]

> Actually, no, sorry ... its a false positive -fno-writeable-strings

Ok the fealnx object wasn't actually a string.

> actually produces an error which was lost in all the debug output (it's
> at the top) so it wasn't working; I only thought it was.

What's the error?

-Andi