CONSTANT_POOL_BEFORE_FUNCTION has no effect in tm.h?
Hello, all. I'm attempting to port GCC 4.4.0 to a new m68k target. The target begins execution in the first byte of the first text section. Adding '#define CONSTANT_POOL_BEFORE_FUNCTION 0' in my target's tm.h seems like the simplest way to avoid execution of read-only data; however, defining the constant has no effect on compilation. (Note, custom or missing startup code is common, so I can't work around it there.) The only references to CONSTANT_POOL_BEFORE_FUNCTION are in varasm.c, and the only target current using the definition is pdp11--not exactly current. Is CONSTANT_POOL_BEFORE_FUNCTION still being used, or have I hit upon a section of dead code? Is there a simple way to relocate read-only data to the end of a function without writing a target-specific reorg routine? Jumping over the data in a prologue might be an easy, quick and dirty solution, but the target is a memory-constrained system, and that seems wasteful. Thanks, Trev
Re: CONSTANT_POOL_BEFORE_FUNCTION has no effect in tm.h?
I guess I'm not understanding the usage of the term constant pool. What I'd like to do is place all constant and read-only data, which I now think means all data affected by CONSTANT_POOL_BEFORE_FUNCTION and READONLY_DATA_SECTION_ASM_OP (and others?); however, I'd like local, read-only data--strings and whatnot--to stay in .text, stored after the function rather than prior to it. More specifically, the data should be stored in a location appropriate for the addressing mode, as long as that location is not before the first instruction in .text. e.g.: .text # NOT HERE .even .globl_main _main: ... rts # HERE LC0: .ascii "this is a string\0" LC1: .ascii "this is another string\0" Will I need to "optimize" the location of the data myself? On Sun, Jul 5, 2009 at 11:14 PM, Ian Lance Taylor wrote: > Setting CONSTANT_POOL_BEFORE_FUNCTION to 0 ought to work to emit the > constant pool after the function. However, to be clear, it only affects > the constant pool which holds constants which are not > LEGITIMATE_CONSTANT_P. This is normally things like 32-bit constants > which RISC architectures can not handle in a single instruction. The > m68k is a flexible architecture and can handle 32-bit constants just > fine without using a constant pool. You didn't really describe what you > are seeing; what makes you think that the constant pool is the problem?
Re: CONSTANT_POOL_BEFORE_FUNCTION has no effect in tm.h?
The target doesn't use ELF. I have .text, .data, and .bss, and read-only data normally goes in .text. I'm learning as I go, so I'll fiddle with a dummy .rodata section of some sort that the linker can position accordingly. On Mon, Jul 6, 2009 at 10:00 AM, Ian Lance Taylor wrote: > Most targets put constant strings and the like in the .rodata section. > Then the linker script can put that in a useful place. That seems like > the best approach to use for a processor like m68k which supports > general addressing. I'm surprised that doesn't happen already. I > assume you are using an ELF target, in which case I would expect > default_elf_select_rtx_section to do the right thing. > > Ian >
Re: CONSTANT_POOL_BEFORE_FUNCTION has no effect in tm.h?
No, that won't work. The assembler only recognizes .text, .data, and .bss and doesn't support .section. Surely there's a simple hook that instructs that compiler to print locals after a function instead of before it? On Mon, Jul 6, 2009 at 10:11 AM, Trevor Scroggins wrote: > The target doesn't use ELF. I have .text, .data, and .bss, and > read-only data normally goes in .text. I'm learning as I go, so I'll > fiddle with a dummy .rodata section of some sort that the linker can > position accordingly. > > On Mon, Jul 6, 2009 at 10:00 AM, Ian Lance Taylor wrote: >> Most targets put constant strings and the like in the .rodata section. >> Then the linker script can put that in a useful place. That seems like >> the best approach to use for a processor like m68k which supports >> general addressing. I'm surprised that doesn't happen already. I >> assume you are using an ELF target, in which case I would expect >> default_elf_select_rtx_section to do the right thing. >> >> Ian >> >
Re: CONSTANT_POOL_BEFORE_FUNCTION has no effect in tm.h?
While I still think the choice is arbitrary (why the front and not the
back--and mine's a lay opinion, I know), what's the generally accepted
method for reorganizing string literals and other constants to appear
after the function asm rather than before it? Some targets appear to
do something similar in TARGET_MACHINE_DEPENDENT_REORG to relocate
read-only data to a safe jump distance. Where should I begin looking
in source/documentation to gain an understanding of the process?
Also, I don't really grok your example, which probably belies a lack
of deep understanding of C or GCC or both. In every case I tried,
'const int ai[] = { 1 };' (and volatile ...) was translated to an
immediate value of 1.
Trev
On Mon, Jul 6, 2009 at 11:45 AM, Ian Lance Taylor wrote:
> Trevor Scroggins writes:
>
>> No, that won't work. The assembler only recognizes .text, .data, and
>> .bss and doesn't support .section. Surely there's a simple hook that
>> instructs that compiler to print locals after a function instead of
>> before it?
>
> No. Why should there be? Even if you fix the case of string constants,
> you will run into trouble as soon as somebody writes
> const int ai[] = { 1 };
>
> Most systems require some sort of startup code to run before main,
> anyhow. If you have no such requirement, then I recommend simply being
> disciplined in how you write the "main" function, or paying the cost of
> two or four initial bytes to branch to the main function from the start
> of the .text section.
>
> Ian
Fwd: CONSTANT_POOL_BEFORE_FUNCTION has no effect in tm.h?
Rather, a safe ref distance. Apologies for the duplicate message.
Trev
-- Forwarded message --
From: Trevor Scroggins
Date: Fri, Jul 10, 2009 at 3:19 PM
Subject: Re: CONSTANT_POOL_BEFORE_FUNCTION has no effect in tm.h?
To: Ian Lance Taylor
Cc: gcc@gcc.gnu.org
While I still think the choice is arbitrary (why the front and not the
back--and mine's a lay opinion, I know), what's the generally accepted
method for reorganizing string literals and other constants to appear
after the function asm rather than before it? Some targets appear to
do something similar in TARGET_MACHINE_DEPENDENT_REORG to relocate
read-only data to a safe jump distance. Where should I begin looking
in source/documentation to gain an understanding of the process?
Also, I don't really grok your example, which probably belies a lack
of deep understanding of C or GCC or both. In every case I tried,
'const int ai[] = { 1 };' (and volatile ...) was translated to an
immediate value of 1.
Trev
On Mon, Jul 6, 2009 at 11:45 AM, Ian Lance Taylor wrote:
> Trevor Scroggins writes:
>
>> No, that won't work. The assembler only recognizes .text, .data, and
>> .bss and doesn't support .section. Surely there's a simple hook that
>> instructs that compiler to print locals after a function instead of
>> before it?
>
> No. Why should there be? Even if you fix the case of string constants,
> you will run into trouble as soon as somebody writes
> const int ai[] = { 1 };
>
> Most systems require some sort of startup code to run before main,
> anyhow. If you have no such requirement, then I recommend simply being
> disciplined in how you write the "main" function, or paying the cost of
> two or four initial bytes to branch to the main function from the start
> of the .text section.
>
> Ian
Re: CONSTANT_POOL_BEFORE_FUNCTION has no effect in tm.h?
> I doubt that there is any documentation on this, but I'd be happy to be
> surprised. TARGET_MACHINE_DEPENDENT_REORG is pretty much free to
> rearrange things however it likes.
>
> If you write
>
> const int ai[] = { 1 };
> int main() { }
>
> then in some cases the global const variable will be put into the
> readonly section of the object file before the function.
Ah. Understood.
/* [static] */ const int ai[] = { 1 };
int main () { }
locates a .long 1 in .text before main() just as
int main ()
{
foo("bar");
}
locates an .ascii "bar\0" in .text before main().
So, I'd have to relocate read-only globals as well.
Trev
