[Bug ld/22751] New: LTO broken for libgcc libcalls

[jcowgill+sourceware at jcowgill dot uk]

https://sourceware.org/bugzilla/show_bug.cgi?id=22751

            Bug ID: 22751
           Summary: LTO broken for libgcc libcalls
           Product: binutils
           Version: 2.30
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: jcowgill+sourceware at jcowgill dot uk
  Target Milestone: ---

From:
https://bugs.debian.org/888478

LD 2.30 seems to mishandle libcalls into libgcc when LTO is enabled.

Testcase for 64-bit architectures (test.c):
volatile  __int128 a = 42;
volatile  __int128 b = 1;

int main(void)
{
        return (int) (a / b);
}

For 32-bit:
volatile unsigned long long a = 42;
volatile unsigned long long b = 1;

int main(void)
{
        return (int) (a / b);
}

Compile with:
gcc -flto -O2 -c test.c
ar rcs libtest.a test.o
gcc -flto -Wl,--whole-archive libtest.a -Wl,--no-whole-archive

[The --whole-archive is not needed in general, but is for this test case]

On x86_64 this gives:
/usr/bin/ld: /tmp/cc8wkDcQ.ltrans0.ltrans.o(.text.startup+0x21): unresolvable
R_X86_64_PLT32 relocation against symbol `__divti3'
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status

On i386:
/usr/bin/ld: /tmp/cc5ZOEfW.ltrans0.ltrans.o(.text.startup+0x3d): unresolvable
R_386_PLT32 relocation against symbol `__udivdi3'
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status

On mipsel (o32 little endian):
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.29.90.20180122 assertion fail
../../bfd/elflink.c:9757
collect2: error: ld returned 1 exit status

I managed to bisect this (on x86_64) to:
1fa4ec6ae707402c6b61cde33cfe4bdeafd53f82 is the first bad commit
commit 1fa4ec6ae707402c6b61cde33cfe4bdeafd53f82
Author: Alan Modra <address@hidden>
Date:   Sat Sep 2 11:08:05 2017 +0930

    LTO rescan archives

    ld ought to be more clever about where it puts LTO recompiled objects.
    Ideally the recompiled objects ought to be ordered to the same place
    their IR objects were, and files extracted from archives on the second
    pass ought to go in the same place as they would if extracted on the
    first pass.  This patch addresses the archive problem.  Without this
    fix, objects extracted from archives might be placed after the crt
    files intended to go at the end of an executable or shared library,
    possibly causing exception handling failures.

            * ldlang.h (lang_input_statement_type): Expand comments.
            (LANG_FOR_EACH_INPUT_STATEMENT): Rewrite without casts.
            * ldlang.c (lang_for_each_input_file): Likewise.
            (load_symbols): Set usrdata for archives.
            (find_rescan_insertion): New function.
            (lang_process): Trim off and reinsert entries added to file chain
            when rescanning archives for LTO.
            * ldmain.c (add_archive_element): Set my_archive input_statement
            next pointer to last element added.

:040000 040000 933c913523934e7984e5f291b407014374cc5aa8
41866e5eae1ab88e83ba47561d9dbbede3ff4231 M      ld

-- 
You are receiving this mail because:
You are on the CC list for the bug.