Why does GCC store pointers in .text segments?

Why does GCC store pointers in .text segments?

[Jim Rodriguez]

To: the helpful people at gcc-help at gcc.gnu.org:

In an embedded application running on an AMCC PowerPC PPC405EP
CPU, I expected that there would be no READS or WRITES into
the true ".text" segment using GCC-4.2.0, but I was wrong.
(I expected it to be execute- or fetch-only conceptually.)


Here is my GCC version information:

[~]$ /usr/local/bin/powerpc-elf-gcc --ver
Using built-in specs.
Target: powerpc-elf
Configured with: ../gcc-4.2.0/configure --prefix=/usr/local/trpz/trpz4.2 
--target=powerpc-elf --enable-64-bit-bfd --disable-libssp
Thread model: single
gcc version 4.2.0



Depicted below is an excerpt from the objdump output
of one of the PPC ELF files.  We found 78 cases of this
situation in the ELF file (which includes 3917 functions).

Each of the 78 cases have an identical look to them,
which is essentially this:

(1) a function ends with its "blr"
(2) the next .text word shows like: .long 0x1579c4
(3) the entry of the next function uses r30 to do a
    read into the .text segment of a pointer which
    points into the .rodata segment


The questions I have are:

(#1):
Why does GCC store certain pointers in the .text segment,
rather than in the .rodata or .data segments?  How does it
choose which pointers deserve to reside in the .text seg?

(#2):
What are these pointers to .rodata officially called?

(#3):
Is there a GCC option that might be used to force
these pointers out of the .text segment?



We were using PPC debug control registers to trigger
on any application software READS or WRITES into the
.text segment, to look for wild-reads or wild-writes,
but this GCC construct -- whatever it's named -- is
defeating the DBCR-read trigger:  we get constant
interrupts from the 78-instances noted.


THANKS for any direction on this topic.  

I tried to search for things like:
GCC pointers stored in text segment

... but got nowhere.  Most group discussions were about
string-constants in .rodata which were still writeable.

Many thanks!
-- Jim R.




SAMPLE_EXCERPT_FROM_OBJDUMP_OF_ELF_FILE:

/data/me/cvs/main/common/util/patricia.c:1141
            }
        }
    }
}
   c2f84:    7f e3 fb 78     mr      r3,r31
   c2f88:    80 01 00 44     lwz     r0,68(r1)
   c2f8c:    7c 08 03 a6     mtlr    r0
   c2f90:    ba 41 00 08     lmw     r18,8(r1)
   c2f94:    38 21 00 40     addi    r1,r1,64
   c2f98:    4e 80 00 20     blr
   c2f9c:    00 15 79 c4     .long 0x1579c4

000c2fa0 <n_doprnt>:
n_doprnt():
static int
n_doprnt(char *obuf, unsigned int obufsize, const char *fmt0, va_list argp)
{
   c2fa0:    94 21 ff 00     stwu    r1,-256(r1)
   c2fa4:    7c 08 02 a6     mflr    r0
   c2fa8:    bd c1 00 b8     stmw    r14,184(r1)
   c2fac:    90 01 01 04     stw     r0,260(r1)
   c2fb0:    42 9f 00 05     bcl-    20,4*cr7+so,c2fb4 <n_doprnt+0x14>
   c2fb4:    7f c8 02 a6     mflr    r30
   c2fb8:    80 1e ff e8     lwz     r0,-24(r30)
   c2fbc:    7f c0 f2 14     add     r30,r0,r30
   c2fc0:    90 61 00 a0     stw     r3,160(r1)
   c2fc4:    7c d2 33 78     mr      r18,r6
/data/me/cvs/main/common/util/printf.c:98
    uchar *fmt;        /* format string */
    int ch;            /* character from fmt */
    int cnt;        /* return value accumulator */
    int n;            /* random handy integer */
    char *t;        /* buffer pointer */
    ulong _ulong = 0;    /* integer arguments %[diouxX] */
        unsigned long long int _ulonglong = 0;  /* long long integer 
arguments %[diouxX] */
    int base;        /* base for [diouxX] conversion */
    int dprec;        /* decimal precision in [diouxX] */
    int fieldsz;        /* field size expanded by sign, etc */
    int flags;        /* flags as above */
    int prec;        /* precision from format (%.3d), or -1 */
    int realsz;        /* field size expanded by decimal precision */
    int size;        /* size of converted field or string */
    int width;        /* width from format (%8d), or 0 */
    char sign;        /* sign prefix (' ', '+', '-', or \0) */
    char *digs;        /* digits for [diouxX] conversion */
    char buf[BUF+1];    /* space for %c, %[diouxX], %[eEfgG] */
    char * bufstart = obuf; /* remember the start of the buffer */

    if (obufsize == 0) {
   c2fc8:    39 20 00 00     li      r9,0
   c2fcc:    91 21 00 9c     stw     r9,156(r1)
   c2fd0:    7c 9b 23 79     mr.     r27,r4
   c2fd4:    41 82 0c a0     beq-    c3c74 <n_doprnt+0xcd4>
/data/me/cvs/main/common/util/printf.c:102
        return 0;
    }

    fmt = (uchar *)fmt0;
   c2fd8:    7c b6 2b 78     mr      r22,r5
   c2fdc:    83 41 00 a0     lwz     r26,160(r1)
   c2fe0:    39 40 00 00     li      r10,0
   c2fe4:    91 41 00 9c     stw     r10,156(r1)
   c2fe8:    3a 20 00 00     li      r17,0
   c2fec:    3a 80 00 00     li      r20,0
   c2ff0:    3a a0 00 00     li      r21,0
   c2ff4:    81 fe 80 00     lwz     r15,-32768(r30)
/data/me/cvs/main/common/util/printf.c:367
    digs = "0123456789abcdef";

Re: Why does GCC store pointers in .text segments?

[Ian Lance Taylor]

Jim Rodriguez <jrodriguez@trpz.com> writes:

> (1) a function ends with its "blr"
> (2) the next .text word shows like: .long 0x1579c4
> (3) the entry of the next function uses r30 to do a
>    read into the .text segment of a pointer which
>    points into the .rodata segment

This sequence is used to get the address of the global offset table when
using -fPIC.  The global offset table is then used to access global
variables.  Since the code is -fPIC, it can't make direct references to
global variables, but must only use offsets.

> (#1):
> Why does GCC store certain pointers in the .text segment,
> rather than in the .rodata or .data segments?  How does it
> choose which pointers deserve to reside in the .text seg?

It doesn't store the pointer in .rodata or .data because there is no
guarantee that it can access .rodata or .data with a 16-bit offset from
the program counter.

> (#2):
> What are these pointers to .rodata officially called?

I would call it a GOT offset.

> (#3):
> Is there a GCC option that might be used to force
> these pointers out of the .text segment?

Assuming you need to use the -fPIC, then I think the -msecure-plt option
will do it, at the cost of an extra instruction in the prologue of every
-fPIC function which needs to access global variables.

Ian