On Wed, Feb 22, 2012 at 12:19 PM, Georg-Johann Lay <a...@gjlay.de> wrote:
> toplev.c emits __gnu_lto markers to assembler:
>
> /* Emit LTO marker if LTO info has been previously emitted. This is
> used by collect2 to determine whether an object file contains IL.
> We used to emit an undefined reference here, but this produces
> link errors if an object file with IL is stored into a shared
> library without invoking lto1. */
> if (flag_generate_lto)
> {
> #if defined ASM_OUTPUT_ALIGNED_DECL_COMMON
> ASM_OUTPUT_ALIGNED_DECL_COMMON (asm_out_file, NULL_TREE,
> "__gnu_lto_v1",
> (unsigned HOST_WIDE_INT) 1, 8);
> #elif defined ASM_OUTPUT_ALIGNED_COMMON
> ASM_OUTPUT_ALIGNED_COMMON (asm_out_file, "__gnu_lto_v1",
> (unsigned HOST_WIDE_INT) 1, 8);
> #else
> ASM_OUTPUT_COMMON (asm_out_file, "__gnu_lto_v1",
> (unsigned HOST_WIDE_INT) 1,
> (unsigned HOST_WIDE_INT) 1);
> #endif
>
> ...
>
> Am I right that this is just used as marker for linker/lto1 to detect presence
> and style of IL representation?
>
> Background is as follows:
>
> A trivial program, compiled for avr and without LTO, at the and of assembler
> output there is
>
> .ident "GCC: (GNU) 4.7.0 20120220 (experimental)"
>
> whereas with the LTO there is:
>
> .comm __gnu_lto_v1,1,1
> .ident "GCC: (GNU) 4.7.0 20120220 (experimental)"
> .global __do_clear_bss
>
> avr only supports static linking.
>
> The avr backend thinks that the symbol occupies space on the silicon and needs
> to be allocated and initialized so that a part of the startup code is dragged
> in which is not needed.
>
> Is it always save to ignore __gnu_lto_* symbols when deciding which parts of
> startup code are needed?
Yes.
We should transition away from emitting __gnu_lto_v1 (which is only used
if you do not use a linker plugin btw) for example by making collect2 use
simple-object from libiberty instead of invoking nm and friends.
Richard.
> Thanks,
>
> Johann
