This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

bug(?): anonymous initialisers go in the .data section, not .rodata


In older versions of gcc, eg 2.95.2, anonymous array or structure
initialisers would go into the .rodata section.  Some of our software
relied on this behaviour.

In newer gcc:
hornet$ gcc -v 
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-85)

these same initialisers go in the .data section, ie they are not
sharable.

To reproduce:

cat >anon-init.c
void foo (void)
{
   const char * const A[] = {"one", "two", 0};
}
^D
oldgcc$ gcc -v
Reading specs from /usr/opt/gcc-lib/i586-pc-linux-gnu/2.95.2/specs
gcc version 2.95.2 19991024 (release)
oldgcc$ gcc -c anon-init.c -o anon-init
oldgcc$ objdump -h anon-init

anon-init:     file format elf32-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000022  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .data         00000000  00000000  00000000  00000058  2**2
                        ^^ note: nothing in the .data section
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000000  00000000  00000000  00000058  2**2
                  ALLOC
  3 .note         00000014  00000000  00000000  00000058  2**0
                  CONTENTS, READONLY
  4 .rodata       00000008  00000000  00000000  0000006c  2**0
                        ^^ note: because it went here
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .comment      00000026  00000000  00000000  00000074  2**0
                  CONTENTS, READONLY

oldgcc$ objdump --version
GNU objdump 2.9.5



But, with newer gcc:

newgcc$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-85)
newgcc$ gcc -c anon-init.c -o anon-init
newgcc$ objdump -h anon-init

anon-init:     file format elf32-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000028  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .data         0000000c  00000000  00000000  0000005c  2**2
                        ^^ note: went in .data section
                  CONTENTS, ALLOC, LOAD, RELOC, DATA
  2 .bss          00000000  00000000  00000000  00000068  2**2
                  ALLOC
  3 .note         00000014  00000000  00000000  00000068  2**0
                  CONTENTS, READONLY
  4 .rodata       00000008  00000000  00000000  0000007c  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .comment      00000036  00000000  00000000  00000084  2**0
                  CONTENTS, READONLY

newgcc$ objdump --version
GNU objdump 2.10.91

Looking at the produced assembly, the strings are put in the .rodata
section correctly, but the array initialiser isn't:

.section        .rodata
.LC0:
        .string "one"
.LC1:
        .string "two"
.data			; this
        .align 4	; is
.LC2:			; the
        .long   .LC0	; stuff
        .long   .LC1	; I'm
        .long   0	; talking about
.text
        .align 4
.globl foo
        .type    foo,@function
foo:
etc etc...

Doesn't "const char * const A[]" mean A is an array of constant
pointers to constant strings - ie the programmer promises not to
modify the array, hence it too can go in the .rodata section.

If the initialiser is placed at file scope, rather than inside a
function, then both versions of gcc put all the data in the .rodata
section as expected:

static const char * const A_init[] = { "one", "two", 0 };
void foo (void)
{
    const char * const * A = A_init;
}

This is the work-around I'm using for the moment.

Austin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]