This is the mail archive of the gcc-help@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]

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


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


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