Re: [PATCH] force LTO to be disabled when compiling dlstart.lo

[Alexander Monakov <amonakov@ispras.ru>]

> This seems to be a common problem then. I helped someone on #gcc with
> almost the exact same issue doing freestanding work making a
> kernel/bare-metal app using LTO a week or so ago. I'm not sure the
> linker plugin can solve the problem since it seems to happen for
> symbol references *within* a single translation unit (or a combined .o
> file produced by ld -r, as in the case of the person on #gcc) which
> the linker plugin probably does not track.

I think I see the root cause now.  The reference to _dlstart_c is from a GCC
asm statement (toplevel in this case), not from a separate assembly file.  The
toplevel asm is part of LTO "bytecode", so when linker symbol resolution runs,
it did not yet have a chance to see the reference from the asm, and GCC is
oblivious to the fact (it would need to parse the asm to notice).

If the person on #gcc with ld -r was using gcc asm statements as well, that
would explain their problem too.

So moving the assembly into its own .s file should avoid the issue; adding
__attribute__((used)) to _dlstart_c fixes it too; but even then ...

> Even if the problem is missing linker plugin though, I think we want
> to avoid LTO on these files. It's likely to be very risky since the
> code is running in a situation where no function calls, global data
> accesses, or symbolic references are possible. Here we really are
> asking the compiler to produce asm for us, rather than asking it to
> produce an optimized way to get an abstract job done.

acknowledged.  Your call :)

Thanks.
Alexander