Re: Why is a const array pointer with -fPIC mapped in ".data"?

[Richard Earnshaw <Richard dot Earnshaw at arm dot com>]

On Wed, 2004-05-19 at 05:14, Kazuomi Kato wrote:
> Thank you for your advice.
> 
> I have some more quetions.
> 
> In the case of the sample program below, "array_const[][]" points to
> the const type "const_rodata".
> So, even if it's compiled with -fPIC option, I guess the relocation
> for the pointer is not needed because "const_rodata" exists
> in the section ".rodata" text area.
> If "array_const[][]" is mapped to the text area, the address of
> "const_rodata" from the "array_const[][]" dosen't relatively change.
> Dose gcc always put the all pointers into ".data" if program's with -fPIC?
> 
> > ===
> > "test.c"
> >
> > const char const_rodata0[] = "test0";
> > const char const_rodata1[] = "test1";
> 
> > const char * const array_const[BUF][2] = {ã/* specified const to array_const */
> >   {const_rodata0, const_rodata1},
> >   {const_rodata2, const_rodata3},
> >   {const_rodata4, const_rodata5}
> > };
> 
> I tried to specify __attribute__ ((section ".rodata")) to the "array_const_attr".
> 
> ==
> "test.c"
> const char * const __attribute__ ((__section__ (".rodata"))) array_const_attr[BUF][2] = {
>   {const_rodata0, const_rodata1},
>   {const_rodata2, const_rodata3},
>   {const_rodata4, const_rodata5}
> };
> ==
> 
> As a result, "array_const_attr[][]" was put into ".rodata" section.
> 
> ==
> $ arm-linux-objdump -T libtest.so
> 00000ab8 g    DO .rodata        00000006  Base        const_rodata1
> 01008b34 g    DO .data  00800000  Base        array_const
> ...
> 00000ae0 g    DO .rodata        00800000  Base        array_const_attr
> ...
> 00808b34 g    DO .data  00800000  Base        array
> ==
> 
> It seems to be successful, but there is a problem.
> Warning occur when assembling the program with __attribute__ ((section ".rodata")).
> 
> ==
> $ arm-linux-gcc -Wall -shared -fPIC -o libtest.so test.c
> /tmp/ccOP5ihJ.s: Assembler messages:
> /tmp/ccOP5ihJ.s:19: Warning: ignoring changed section attributes for .rodata
> ==
> 
> gas try to make the "array_const_attr", but ".rodata" attributes not writable,
> so "array_const_attr" is put into ".rodata" with original attributes.
> This result is OK for me, but I mind the warning.
> Is the warning fatal?

I think you are missing the point of -fPIC.  We want code to be position
independent if we want to share it amongst multiple applications which
each need the code to execute the code at a different address.  Making
the code position independent enables the operating system to map it at
any address it deems fit without having to make a copy (in another page
of RAM) that is modified for that address.

Pointers in general are not position independent, they are absolute and
so can't be shared across all the copies of the executing code.  If we
put absolute addresses in the read-only section then it can either
no-longer be shared or it must be executed at a fixed address.  If it's
the latter then why bother to make the code position-independent in the
first place, since it's invariably less efficient than absolute
addressing.

So the compiler tries to help you.  It puts data objects that are
read-only and don't contain pointer in the read-only section, but puts
data objects that contain pointers in the read-write section.  That way
the smallest number of pages overall have to be fixed up when you start
to execute your application.

What's happening in the above case, where you've tried to force the
compiler's hand is that it's tried to give the read-only section
(.rodata) the writeable attribute (if you look at the assembly file
produced by the compiler you will see:

        .section        .rodata,"aw",%progbits

That 'w' in "aw" means the section should be writable.  Of course, that
conflicts with the attributes that the assembler things .rodata should
have, so it complains.  As to whether or not this matters, I don't know;
it may be that things will compile, but that you will find that they
just fail to execute correctly at run time.

So I think you need to ask yourself a few questions.

- Is PIC really what you want?

- Do you really want to have absolute addresses in the READ-ONLY
section? (since that means it's not really PIC).

However, you could also look at Alexandre's suggestion, it might solve
your particular needs.

R.