|
Message-ID: <alpine.LNX.2.11.1504282131510.22867@monopod.intra.ispras.ru> 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.