[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 28 Apr 2015 21:41:14 +0300 (MSK)
From: Alexander Monakov <amonakov@...ras.ru>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] force LTO to be disabled when compiling
dlstart.lo
> 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
