2009-06-22 08:04:37

by Stephen Rothwell

[permalink] [raw]
Subject: [PATCH] fbdev: work around old compiler bug

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 <[email protected]>
---
scripts/pnmtologo.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/scripts/pnmtologo.c b/scripts/pnmtologo.c
index 64f5ddb..d10c389 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);
}

--
1.6.3.1


--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/


2009-06-22 08:34:28

by Stephen Rothwell

[permalink] [raw]
Subject: Re: [PATCH] fbdev: work around old compiler bug

On Mon, 22 Jun 2009 18:04:20 +1000 Stephen Rothwell <[email protected]> wrote:
>
> When building with a 4.1.x compiler on powerpc64 (at least) we get
> this error:

Ignore this, it causes more problems:

drivers/video/logo/logo_linux_clut224.c:548: error: logo_linux_clut224_clut causes a section type conflict

I'll work on a better solution.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/


Attachments:
(No filename) (450.00 B)
(No filename) (197.00 B)
Download all attachments

2009-06-22 09:39:34

by Sam Ravnborg

[permalink] [raw]
Subject: Re: [PATCH] fbdev: work around old compiler bug

On Mon, Jun 22, 2009 at 06:34:15PM +1000, Stephen Rothwell wrote:
> On Mon, 22 Jun 2009 18:04:20 +1000 Stephen Rothwell <[email protected]> wrote:
> >
> > When building with a 4.1.x compiler on powerpc64 (at least) we get
> > this error:
>
> Ignore this, it causes more problems:
>
> drivers/video/logo/logo_linux_clut224.c:548: error: logo_linux_clut224_clut causes a section type conflict
>
> I'll work on a better solution.

I have no time to experiemnt atm.
But I have seen this before.
It happens when we mix up const and non-const stuff.

I would assume the simple solution is to replace _initconst with _initdata
for all users.
If you get it to work with powerpc then it works for everyone (or so it is usually).

Sam

2009-06-23 05:44:37

by Stephen Rothwell

[permalink] [raw]
Subject: [PATCH v2] fbdev: work around old compiler bug

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 <[email protected]>
---
scripts/pnmtologo.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)

v2: also convert _clut arrays from __initconst to __initdata.

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++) {
--
1.6.3.1

--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/

2009-06-23 16:45:26

by Kyle McMartin

[permalink] [raw]
Subject: Re: [PATCH v2] fbdev: work around old compiler bug

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

2009-06-23 19:21:05

by Sam Ravnborg

[permalink] [raw]
Subject: Re: [PATCH v2] fbdev: work around old compiler bug

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