Mail Archives: djgpp-workers/2013/12/08/19:54:24
Am 03.12.2013 18:44, schrieb Andris Pavenis:
> On 12/03/2013 04:05 PM, Juan Manuel Guerrero wrote:
>> Am 23.11.2013 15:26, schrieb Andris Pavenis:
>>> On 11/23/2013 03:49 PM, Juan Manuel Guerrero wrote:
>>>> Am 23.11.2013 09:25, schrieb Andris Pavenis:
>>>>> We should discard .gnu.lto_* sections in linker similarly as it
>>>>> is done for Linux
>>>>>
>>>>> /DISCARD/: { *(gnu.lto_*) }
>>>>>
>>>>> Now that at least for current development version of GCC (4.9)
>>>>> one can with some additional modifications enable LTO it would
>>>>> be nice to have support for it also in binutils
>>>>>
>>>>> The related source file is ld/scripttempl/i386go32.sc
>>>>>
>>>>> Andris
>>>>>
>>>>
>>>> Do you need a new release of bnu2232 with the linker script that has the
>>>> DISCARD line added?
>>>>
>>>>
>>> I guess, it is not urgent. We do not yet have released version of GCC
>>> for DJGPP which supports LTO. It is not critical problem like broken
>>> debugging info support, so it can wait. gcc-4.8.3 or gcc-4.9.0 release
>>> is not expected very soon also.
>>>
>>> I could also build binutils myself if needed (although I would perhaps
>>> do it under Linux using cross-compiling instead of native build for DJGPP)
>>>
>>> Also if one likes to check out, then build of snapshot with LTO support
>>> enabled can be found at:
>>>
>>> http://ap1.pp.fi/djgpp/gcc/test/4.9.0-20131121/
>>>
>>> I have not done much testing with it. Build bash-2.0.5b using it and
>>> specified CFLAGS="-O2 -g -flto" for building. All seemed to work.
>>>
>>> Andris
>>>
>>>
>>>
>>>
>>
>> In a couple of days I would like to upload the port of binutils 2.24.
>> Apart from the usual changes to i386go32.sc that are not showed in the
>> patch below, do you need some other LTO specific changes that must go
>> into the port? I will look at the sources anyway but you may be more
>> familiar with the LTO stuff.
>>
>>
>
> I only tried whether I can get it to work for DJGPP and specified -flto when
> building bash-2.05b for DJGPP. Seemed to work.
>
> I tested linker script update by providing modified linker script with one
> line added (as below) and provided it using GCC command line option -T
> without actually rebuilding binutils.
>
>>
>>
>> diff -aprNU10 binutils-2.24.orig/ld/scripttempl/i386go32.sc binutils-2.24/ld/scripttempl/i386go32.sc
>> --- binutils-2.24.orig/ld/scripttempl/i386go32.sc 2013-11-04 15:33:38 +0100
>> +++ binutils-2.24/ld/scripttempl/i386go32.sc 2013-12-03 14:33:56 +0100
>> @@ -63,12 +63,13 @@ SECTIONS
>> ${RELOCATING+ . = ALIGN(${SEGMENT_SIZE});}
>> }
>> /* Stabs debugging sections. */
>> .stab 0 : { *(.stab) }
>> .stabstr 0 : { *(.stabstr) }
>> EOF
>>
>> . $srcdir/scripttempl/DWARF.sc
>>
>> cat <<EOF
>> + /DISCARD/: { *(gnu.lto_*) }
>> }
>> EOF
>>
>>
>>
>
> You can test it using mu build of gcc snapshot I mentioned before. Look whether
> LTO related sections are discarded in executable. Even simple hello world style
> program is sufficient for this test
>
> Andris
>
I have installed gcc490_20131121b.zip and my port of binutils-2.24 that
discards the lto sections. As long as I do not use the -flto flag the
compiler works flawlessly but as soon as I use the flag the compiler
aborts. I have tried a hello-world program and I got the following
error output:
G:\>gcc -flto a.c
gcc.exe: internal compiler error: (program lto1)
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
lto-wrapper: c:/djgpp-2.04/bin/gcc.exe returned 4 exit status
collect2.exe: error: lto-wrapper returned 1 exit status
I have also tried to compile bash as you have done but because the compiler
produces no output the configuration stops.
If more info is required, please contact me.
Regards,
Juan M. Guerrero
- Raw text -