On 05.21 Richard Henderson wrote:
> On Mon, May 21, 2001 at 01:07:50PM +1000, Keith Owens wrote:
> > does cause a section conflict, egcs 1.1.2.
> >
> > Interestingly enough, if var[12] are together, without the intervening
> > text, then gcc does not flag an error, instead it puts both
Richard Henderson wrote:
> No, the problem is not with which section, but what flags that
> section should have. If you put only "const" data in a section,
> then the section should have SHF_WRITE clear. Conversely, if
> you put writable data in a section then SHF_WRITE should be set.
>
> Now,
On Mon, May 21, 2001 at 01:07:50PM +1000, Keith Owens wrote:
> does cause a section conflict, egcs 1.1.2.
>
> Interestingly enough, if var[12] are together, without the intervening
> text, then gcc does not flag an error, instead it puts both variables
> in section .data.init and marks it as
On Sun, 20 May 2001 17:34:48 -0400,
Jeff Garzik <[EMAIL PROTECTED]> wrote:
>(let me know if the following test is flawed)
>
> [jgarzik@rum tmp]$ cat > sectest.c
> #include
> #include
> static const char version[] __initdata = "foo";
> [jgarzik@rum tmp]$ gcc -D__KERNEL__
On Sun, 20 May 2001 17:34:48 -0400,
Jeff Garzik [EMAIL PROTECTED] wrote:
(let me know if the following test is flawed)
[jgarzik@rum tmp]$ cat sectest.c
#include linux/module.h
#include linux/init.h
static const char version[] __initdata = foo;
[jgarzik@rum tmp]$ gcc -D__KERNEL__
On Mon, May 21, 2001 at 01:07:50PM +1000, Keith Owens wrote:
does cause a section conflict, egcs 1.1.2.
Interestingly enough, if var[12] are together, without the intervening
text, then gcc does not flag an error, instead it puts both variables
in section .data.init and marks it as read
Richard Henderson wrote:
No, the problem is not with which section, but what flags that
section should have. If you put only const data in a section,
then the section should have SHF_WRITE clear. Conversely, if
you put writable data in a section then SHF_WRITE should be set.
Now, one
On 05.21 Richard Henderson wrote:
On Mon, May 21, 2001 at 01:07:50PM +1000, Keith Owens wrote:
does cause a section conflict, egcs 1.1.2.
Interestingly enough, if var[12] are together, without the intervening
text, then gcc does not flag an error, instead it puts both variables
in
On Mon, May 21, 2001 at 12:19:49AM +0200, Ingo Oeser wrote:
> AFAIK "const" is only a promise to the compiler, that we write
> this data ONCE and read only after this initial write. So the
> decision on the section is implementation defined.
No, the problem is not with which section, but what
On Sun, 20 May 2001 22:16:11 +0200,
Franz Sirl <[EMAIL PROTECTED]> wrote:
>Yes, and gcc3 errors on these constructs, cause it cannot decide if the data
>should be put into a .data or .rodata section.
>Dunno if it's worth to create a __initconstdata/__initrodata though, but it
>would be easy
On Sun, May 20, 2001 at 05:34:48PM -0400, Jeff Garzik wrote:
> This might be a very valid point...
>
> (let me know if the following test is flawed)
It is imho.
> > [jgarzik@rum tmp]$ cat > sectest.c
> > #include
> > #include
> > static const char version[] __initdata = "foo";
static
On Sun, May 20, 2001 at 09:51:04PM +0200, Geert Uytterhoeven wrote:
> Appendix: here's the list of affected source files:
>
> arch/arm/kernel/setup.c
Thanks for pointing it out.
--
Russell King ([EMAIL PROTECTED])The developer of ARM Linux
Geert Uytterhoeven wrote:
>
> On Sun, 20 May 2001, Jeff Garzik wrote:
> > Geert Uytterhoeven wrote:
> > > Since a while include/linux/init.h contains the line
> > >
> > > * Also note, that this data cannot be "const".
> > >
> > > Why is this? Because const data will be put in a different
On Sun, 20 May 2001, Jeff Garzik wrote:
> Geert Uytterhoeven wrote:
> > Since a while include/linux/init.h contains the line
> >
> > * Also note, that this data cannot be "const".
> >
> > Why is this? Because const data will be put in a different section?
>
> Causes a "section type
On Sunday 20 May 2001 21:51, Geert Uytterhoeven wrote:
> Since a while include/linux/init.h contains the line
>
> * Also note, that this data cannot be "const".
>
> Why is this? Because const data will be put in a different section?
Yes, and gcc3 errors on these constructs, cause it cannot
Geert Uytterhoeven wrote:
>
> Since a while include/linux/init.h contains the line
>
> * Also note, that this data cannot be "const".
>
> Why is this? Because const data will be put in a different section?
Causes a "section type conflict" build error, at least on x86.
> FWIW, many
Since a while include/linux/init.h contains the line
* Also note, that this data cannot be "const".
Why is this? Because const data will be put in a different section?
However, quite some code defines const __init variables (see list below).
So what should be done now?
1. Re
On Sunday 20 May 2001 21:51, Geert Uytterhoeven wrote:
Since a while include/linux/init.h contains the line
* Also note, that this data cannot be const.
Why is this? Because const data will be put in a different section?
Yes, and gcc3 errors on these constructs, cause it cannot decide
On Sun, 20 May 2001, Jeff Garzik wrote:
Geert Uytterhoeven wrote:
Since a while include/linux/init.h contains the line
* Also note, that this data cannot be const.
Why is this? Because const data will be put in a different section?
Causes a section type conflict build error,
On Sun, May 20, 2001 at 09:51:04PM +0200, Geert Uytterhoeven wrote:
Appendix: here's the list of affected source files:
arch/arm/kernel/setup.c
Thanks for pointing it out.
--
Russell King ([EMAIL PROTECTED])The developer of ARM Linux
On Sun, May 20, 2001 at 05:34:48PM -0400, Jeff Garzik wrote:
This might be a very valid point...
(let me know if the following test is flawed)
It is imho.
[jgarzik@rum tmp]$ cat sectest.c
#include linux/module.h
#include linux/init.h
static const char version[] __initdata = foo;
On Mon, May 21, 2001 at 12:19:49AM +0200, Ingo Oeser wrote:
AFAIK const is only a promise to the compiler, that we write
this data ONCE and read only after this initial write. So the
decision on the section is implementation defined.
No, the problem is not with which section, but what flags
22 matches
Mail list logo
