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

["Kazuomi Kato" <kato dot kazuomi at jp dot panasonic dot com>]

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?

Thank you, in advance.
Kazuomi Kato

----- Original Message ----- 
From: "Richard Earnshaw" <Richard.Earnshaw@arm.com>
Sent: Monday, May 17, 2004 8:02 PM
Subject: Re: Why is a const array pointer with -fPIC mapped in ".data"?


> On Mon, 2004-05-17 at 11:39, Kazuomi Kato wrote:
> > I'd like to put an array data in the section ".rodata".
> > I wish the array data to be unmodified so I used const type for it.
> > However, inspite of the data specified as const type, I found the case
> > that the data specified was mapped in the section ".data".
> > If a const pointer array is compiled with -fPIC option, const type
> > to the pointer is ignored and the pointer exists in the ".data".
> >
> > Do you know why this is happening?
>
> Yes.
> > Does the -fPIC option have to do with above phenomenon?
>
> Yes.
>
> The problem is that when the code is loaded it has to be dynamically
> relocated (the pointers in the data have to be adjusted based on the
> load address).  Because of this, it can't be made read-only (at least,
> not without having the dynamic loader playing page protection dances in
> the MMU).
>
> So although your code is not logically modifiable (from the strict
> source-code perspective), it does have to be physically modifiable from
> the execution perspective.
>
> If you really want your PIC data tables to be read-only, don't put
> pointers in them.
>
> R.
>
> >
> > I used the gcc v3.2.1 for ARM.
> >
> > I'd like to show an example bellow.
> > ===
> > "test.c"
> >
> > const char const_rodata0[] = "test0";
> > const char const_rodata1[] = "test1";
> > const char const_rodata2[] = "test2";
> > const char const_rodata3[] = "test3";
> > const char const_rodata4[] = "test4";
> > const char const_rodata5[] = "test5";
> >
> > const char * const array_const[BUF][2] = {縲€/* specified const to array_const */
> >   {const_rodata0, const_rodata1},
> >   {const_rodata2, const_rodata3},
> >   {const_rodata4, const_rodata5}
> > };
>