Hi R0b0t1,
Thanks for your reply!
That helps me a lot, and now I know it's a more complicated question
than I've thought.
I'm using GCC on X86_64, more specially, on linux x86_64. I also find
that when compiling with -O2, GCC will emits some data(like const
string or const int) into .text. I wonder if I could forbid this by
setting some GCC optimization options? I want to eliminate such data
in the code sections, and put them into data sections.
2017-06-28 12:40 GMT+08:00 R0b0t1 <r03...@gmail.com>:
> On Tue, Jun 27, 2017 at 11:00 PM, Benxi Liu <lbxlbxlbxlbx...@gmail.com> wrote:
>> Hello everyone,
>> I'm using GCC 5.4.0. I know that in some situations, GCC will put
>> data into .text section, to improve performance. I know one case is
>> jump table, but I'm still curious about other cases. What kind of data
>> will be put into executable sections? Is there any way to avoid this?
>> Any ideas?
>
> This is rather hard to answer because what .text and .data actually
> are depends very heavily on the target architecture. Except for very
> specific optimizations it doesn't matter. When it does, the compiler
> knows better than you.
>
> On von Neumann machines there is effectively no difference between
> .text and .data (or .bss) so the location of information is simply a
> nicety for the programmer. As far as optimizations go you could put
> data into .text when you need to ensure that it is very close in
> memory to the code that operates on it, but on modern machines
> instruction and data caches are separate. The vast majority of
> optimizations rely on reducing the number of comparisons and ensuring
> execution is as linear as possible. Where memory is located matters
> far less than what you are doing with it and how you are doing it.
>
> On Harvard architecture machines .text and .data are different and
> usually wildly so. Most simple microcontrollers treat .data in a
> special way - on the device it exists in the program memory, but the
> standard library loads it in to RAM at runtime. It is common to want
> more information available than can readily be loaded into memory.
> This is accomplished by marking the relevant variables with
> __attribute__((section(".rodata"))), __ATTR_PROGMEM__, PROGMEM, etc
> (implementation dependent). They must be swapped into and out of RAM
> manually using special instructions for reading the program memory.
> These instructions may have special forms for reading sequential
> blocks of memory, and the memory controller may perform best when
> reading sequentially. In these cases how you organize your data
> matters, but reading program memory with the relevant instructions is
> still separate (always, as far as I know) from the instruction fetcher
> that is always reading program memory for the processor, so there's no
> inherent benefit to interleaving code and data.
>
> R0b0t1.
