This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: LTO vs GCC 8


On May 15, 2018 10:12:45 PM GMT+02:00, Freddie Chopin <freddie_chopin@op.pl> wrote:
>On Tue, 2018-05-15 at 21:39 +0200, Freddie Chopin wrote:
>> On Fri, 2018-05-11 at 18:51 +0200, Richard Biener wrote:
>> > As to a workaround for the ld bug you can try keeping all .debug_*
>> > sections. IIRC 2.30 has the bug fixed (on the branch). 
>> 
>> Indeed - "keeping" all the debug sections is a viable alternative.
>> I've
>> found out that it is enough to "keep" just these:
>> 
>> 	/* DWARF 2 */
>> 	.debug_info 0 : { KEEP(*(.debug_info .gnu.linkonce.wi.*)); }
>> 	 ...
>> 	.debug_frame 0 : { KEEP(*(.debug_frame)); }
>> 
>> I have to check whether debugging something like that is actually
>> possible (; Thanks for the workaround!
>
>Nope, sent it too fast... With these two (three) sections "kept" --gc-
>sections stops working and the executable I get is almost identical to
>the case when I have no --gc-sections at all:
>- lto + --gc-sections, sections "kept" - 133504 ROM + 4196 RAM
>- lto + --gc-sections, sections not "kept" (causes previously mentioned
>errors) - 120288 ROM + 3676 RAM
>- lto, sections not "kept" - 133812 ROM + 4220 RAM
>
>So it seems I have to patiently wait for new binutils if I would like
>to use LTO (;

Build your own (patched) binutils :) 

Richard. 

>Regards,
>FCh


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]