diff mbox

[v2] fbdev: work around old compiler bug

Message ID 20090623154428.e2f4ddc9.sfr@canb.auug.org.au (mailing list archive)
State Not Applicable, archived
Headers show

Commit Message

Stephen Rothwell June 23, 2009, 5:44 a.m. UTC
When building with a 4.1.x compiler on powerpc64 (at least) we get
this error:

drivers/video/logo/logo_linux_mono.c:81: error: logo_linux_mono causes a section type conflict

This was introduced by commit ae52bb2384f721562f15f719de1acb8e934733cb
("fbdev: move logo externs to header file").  This is a partial revert
of that commit sufficient to not hit the compiler bug.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 scripts/pnmtologo.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

v2: also convert _clut arrays from __initconst to __initdata.

Comments

Kyle McMartin June 23, 2009, 4:45 p.m. UTC | #1
On Tue, Jun 23, 2009 at 03:44:28PM +1000, Stephen Rothwell wrote:
> When building with a 4.1.x compiler on powerpc64 (at least) we get
> this error:
> 
> drivers/video/logo/logo_linux_mono.c:81: error: logo_linux_mono causes a section type conflict
> 
> This was introduced by commit ae52bb2384f721562f15f719de1acb8e934733cb
> ("fbdev: move logo externs to header file").  This is a partial revert
> of that commit sufficient to not hit the compiler bug.
> 

We're seeing similar issues with 4.3 on parisc (the case I saw today was
in fs/nfs/nfsroot.c...) Any ideas on the actual culprit or is it just
gcc being unfriendly?

regards, Kyle
Sam Ravnborg June 23, 2009, 7:23 p.m. UTC | #2
On Tue, Jun 23, 2009 at 12:45:05PM -0400, Kyle McMartin wrote:
> On Tue, Jun 23, 2009 at 03:44:28PM +1000, Stephen Rothwell wrote:
> > When building with a 4.1.x compiler on powerpc64 (at least) we get
> > this error:
> > 
> > drivers/video/logo/logo_linux_mono.c:81: error: logo_linux_mono causes a section type conflict
> > 
> > This was introduced by commit ae52bb2384f721562f15f719de1acb8e934733cb
> > ("fbdev: move logo externs to header file").  This is a partial revert
> > of that commit sufficient to not hit the compiler bug.
> > 
> 
> We're seeing similar issues with 4.3 on parisc (the case I saw today was
> in fs/nfs/nfsroot.c...) Any ideas on the actual culprit or is it just
> gcc being unfriendly?

Al analysed this some time ago.
When we say something is const then _sometimes_ gcc annotate the
section as const(*) - sometimes not.
So if we have two variables/functions annotated __*const and
gcc decides to annotate the section const only in one case
we get a section type conflict.

(*) it is named something else I do not recall at the moment
in linker language.

	Sam
diff mbox

Patch

diff --git a/scripts/pnmtologo.c b/scripts/pnmtologo.c
index 64f5ddb..5c11312 100644
--- a/scripts/pnmtologo.c
+++ b/scripts/pnmtologo.c
@@ -237,7 +237,7 @@  static void write_header(void)
     fprintf(out, " *  Linux logo %s\n", logoname);
     fputs(" */\n\n", out);
     fputs("#include <linux/linux_logo.h>\n\n", out);
-    fprintf(out, "static const unsigned char %s_data[] __initconst = {\n",
+    fprintf(out, "static unsigned char %s_data[] __initdata = {\n",
 	    logoname);
 }
 
@@ -374,7 +374,7 @@  static void write_logo_clut224(void)
     fputs("\n};\n\n", out);
 
     /* write logo clut */
-    fprintf(out, "static const unsigned char %s_clut[] __initconst = {\n",
+    fprintf(out, "static unsigned char %s_clut[] __initdata = {\n",
 	    logoname);
     write_hex_cnt = 0;
     for (i = 0; i < logo_clutsize; i++) {