CONSTANT_POOL_BEFORE_FUNCTION has no effect in tm.h?

[Trevor Scroggins-2]

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

[Ian Lance Taylor-3]

Trevor Scroggins <trevor.scroggins@...> writes:

> 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.

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?

Ian

[Trevor Scroggins-2]

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<iant@...> 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?

[Ian Lance Taylor-3]

Trevor Scroggins <trevor.scroggins@...> writes:

> 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?

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

[Trevor Scroggins-2]

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<iant@...> 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
>

[Trevor Scroggins-2]

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<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<iant@...> 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
>>
>

[Ian Lance Taylor-3]

Trevor Scroggins <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

[Trevor Scroggins-2]

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<iant@...> wrote:

> Trevor Scroggins <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

[Trevor Scroggins-2]

Rather, a safe ref distance. Apologies for the duplicate message.

Trev

---------- Forwarded message ----------
From: Trevor Scroggins <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 <iant@...>
Cc: gcc@...


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<iant@...> wrote:

> Trevor Scroggins <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

[Ian Lance Taylor-3]

Trevor Scroggins <trevor.scroggins@...> writes:

> 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?

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.

> 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.

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.

Ian

[Trevor Scroggins-2]

> 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