Bug ID: 85801
           Summary: LTO linking fails to reconcile symbol from common an
                    data sections (-fPIE -Wl,--as-needed -flto):
                    unresolvable R_ARM_REL32 relocation against symbol
           Product: gcc
           Version: 8.0.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot
          Reporter: slyfox at inbox dot ru
                CC: marxin at gcc dot
  Target Milestone: ---

This failure is not arm-specific but architecture-specific. It was found on
slightly patched xfsprogs in

Here is a complete example that illustrates the failure:

  // $ cat libxfs.c 
    char * progname = "libxfs"; /* tools will override it */
    const char * my_name(void) { return progname; }

  // $ cat xfs_io.c 
    #include <stdio.h>

    // this would be more precise:
    //   extern char * progname;
    // but libxfs uses this:
    char * progname;

    // from libxfs
    const char * my_name(void);

    int main(int argc, char ** argv) {
        progname = argv[0];
        fprintf(stderr, "I am %s\n", my_name());
        return progname[0];

  // $ cat

    export LANG=C

    : ${CC:=gcc}

    $CC -flto                 -fPIC -shared libxfs.c -o
    $CC -flto -Wl,--as-needed -fPIE -pie    xfs_io.c -o bug_tool -L . -lxfs

- 'char * progname' is defined in both units. Is it valid C? Is it OK to rely
on linker to resolve this ambiguity?
- Both -Wl,--as-needed and -flto seem to be required to trigger the bug

Broken targets:

 CC=/usr/bin/aarch64-unknown-linux-gnu-gcc ./
    ld: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `progname' which
may bind externally can not be used when making a shared object; recompile with
    ld: unresolvable R_AARCH64_ADR_PREL_PG_HI21 relocation against symbol
 CC=/usr/bin/alpha-unknown-linux-gnu-gcc ./
    ld: gp-relative relocation against dynamic symbol progname
 CC=/usr/bin/armv5tel-softfloat-linux-gnueabi-gcc ./
 CC=/usr/bin/armv7a-hardfloat-linux-gnueabi-gcc ./
    ld: unresolvable R_ARM_REL32 relocation against symbol `progname'
 CC=/usr/bin/ia64-unknown-linux-gnu-gcc ./
    ld: @gprel relocation against dynamic symbol progname
 CC=/usr/bin/powerpc64-unknown-linux-gnu-gcc ./
 CC=/usr/bin/powerpc64le-unknown-linux-gnu-gcc ./
    ld: final link failed: Symbol needs debug section which does not exist
 CC=/usr/bin/riscv64-unknown-linux-gnu-gcc ./
    ld: unresolvable R_RISCV_PCREL_HI20 relocation against symbol `progname'
 CC=/usr/bin/s390x-unknown-linux-gnu-gcc ./
    ld: `progname' non-PLT reloc for symbol defined in shared library and
accessed from executable (rebuild file with -fPIC ?)
 CC=/usr/bin/sh4-unknown-linux-gnu-gcc ./
    ld: unresolvable R_SH_GOTOFF relocation against symbol `progname'
 CC=/usr/bin/x86_64-pc-linux-gnu-gcc ./

Seemingly working targets (by chance or lack support for one of modes):

 CC=/usr/bin/hppa-unknown-linux-gnu-gcc ./
 CC=/usr/bin/hppa2.0-unknown-linux-gnu-gcc ./
 CC=/usr/bin/m68k-unknown-linux-gnu-gcc ./
 CC=/usr/bin/mips-unknown-linux-gnu-gcc ./
 CC=/usr/bin/mips64-unknown-linux-gnu-gcc ./
 CC=/usr/bin/mips64el-unknown-linux-gnu-gcc ./
 CC=/usr/bin/mipsel-unknown-linux-gnu-gcc ./
 CC=/usr/bin/nios2-unknown-linux-gnu-gcc ./
 CC=/usr/bin/powerpc-unknown-linux-gnu-gcc ./
 CC=/usr/bin/s390-unknown-linux-gnu-gcc ./
 CC=/usr/bin/sparc-unknown-linux-gnu-gcc ./
 CC=/usr/bin/sparc64-unknown-linux-gnu-gcc ./

Should xfsprogs be fixed to specify correct declarations?
Should gcc be fixed to handle this case for all(most) targets uniformly?


Reply via email to