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

[Khem Raj <raj.khem@gmail.com>]

On Tue, Apr 28, 2015 at 6:43 AM, Rich Felker <dalias@libc.org> wrote:
> On Tue, Apr 28, 2015 at 11:35:18AM +0300, Alexander Monakov wrote:
>> Hello,
>>
>> Sorry for not joining the discussion earlier.
>>
>> Andre, can you specify your GCC and Binutils version?  The reason I ask, with
>> modern toolchain you shouldn't be seeing the error you reported.  The fact
>> that _dlstart_c function is used from assembly should have been communicated
>> from the linker to the compiler via the "linker plugin".  If linker plugin was
>> not used, that would explan the problem.
>>
>> Can you also check if adding '-fuse-linker-plugin' to '-flto' works for you?
>>
>> For reference, with GCC 4.9 that uses linker plugin for LTO automatically, I
>> get the following diagnostics:
>>
>> /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/../../../../x86_64-pc-linux-gnu/bin/ld:
>> error: /tmp/ccxxkwJ8.ltrans0.ltrans.o: requires dynamic R_X86_64_PC32 reloc
>> against '_dlstart_c' which may overflow at runtime; recompile with -fPIC
>> /tmp/ccxxkwJ8.ltrans0.ltrans.o(.text+0x12): error: undefined reference to
>> '_dlstart_c'
>>
>> Not saying the patch can't go in -- just want to make sure everyone on the
>> same page regarding the origin of the problem and GCC LTO capabilities.
>

 with -flto you have to make sure that you use a version of binutils
that supports gcc's liblto_plugin. Since version 4.9 gcc produces slim
object files that only contain the intermediate representation. In
order to handle archives of these objects you have to use the gcc
wrappers: gcc-ar, gcc-nm and gcc-ranlib

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