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]

RE: distinguishing .text SYMBOL_REF's from .data SYMBOL_REF's


Philippe De Muyter wrote:
> For a mmu-less embedded target, I would like to generate code to run at
> a fixed location in read-only memory, but with the data segment located
> anywhere in memory.  Therefore, the accesses to the data segement must go
> through an indirection table (GOT).
> 
> I do not think that the option exists for my target (m68k).
> 
> In order to implement it I should be able to distinguish SYMBOL_REF's to
> the text+rodata segment from SYMBOL_REF's to the data+bss segment.
> 
> Does that already exist ?

  It isn't completely possible, since it's the linker that has the final say
on where objects get placed in memory, not the compiler.

  It is possible to determine which sections function and data symbols are
being placed into as they are compiled in the current compilation-unit, but it
isn't possible to tell in advance from a forward reference, and nor is it
possible to know what section a symbol from a different compilation unit
refers to, since there is not enough information from an 'extern' reference to
decide.

  Generally, distinguishing between symbol refs on the basis of details of
what they actually refer to has to be done by implementing
TARGET_ENCODE_SECTION_INFO; at that time you have both the tree DECL and the
SYMBOL_REF available and you can record the information you need.  See the
internals manual for T_E_S_I, and take a look at the rs6000 or ARM ports for
how they use it to implement long-vs-short call sequences.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


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