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.