[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMKF1soiqa_P7Ac3gjn-2yfJEU96M1xVOJJ9yAkFSK--5227iw@mail.gmail.com>
Date: Tue, 28 Apr 2015 07:48:23 -0700
From: Khem Raj <raj.khem@...il.com>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] force LTO to be disabled when compiling dlstart.lo
On Tue, Apr 28, 2015 at 6:43 AM, Rich Felker <dalias@...c.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
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.
