[Bug 1767223] Re: multilib selects wrong start files

Launchpad Bug Tracker 1767223 at bugs.launchpad.net
Wed Dec 19 00:17:29 UTC 2018


Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: newlib (Ubuntu Cosmic)
       Status: New => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1767223

Title:
  multilib selects wrong start files

Status in newlib package in Ubuntu:
  Confirmed
Status in newlib source package in Bionic:
  Triaged
Status in newlib source package in Cosmic:
  Confirmed
Status in newlib source package in Disco:
  Confirmed

Bug description:
  [Impact]

  This bug prevents users to produce binaries for some of the targets
  supported by the compiler. In some case, binaries can get produced but
  will fail to execute properly.

  To fix this issue the package needs to be rebuilt from the same
  source. Risk of regressions are thus limited to an issue in the arm-
  none-eabi toolchain used for the rebuild.

  The bug stems from newlib having libraries for various targets (called
  multilib) in a different location than where the compiler expects them
  to be, thus making the wrong libraries get selected. The location of
  the newlib libraries is decided at build time by asking the compiler
  (provided in gcc-arm-none-eabi) where it will be looking for these.
  Unfortunately, the version of newlib in Ubuntu bionic was built using
  a different version of gcc-arm-none-eabi than the one currently in
  bionic and GCC changed where to look for library between those 2
  versions. This is why rebuilding against the current gcc-arm-none-eabi
  will solve the issue.

  [Test Case]

  Compile the following hello world testcase (in hello.c) with arm-none-
  eabi-gcc -o hello.axf hello.c -mthumb -Wl,--gc-sections -ffast-math
  -march=armv7e-m -specs=rdimon.specs

  #include <stdio.h>

  int
  main (void)
  {
    puts ("Hello, World!");
    return 0;
  }

  [Regression Potential]

  As explained in the impact, no source change is necessary so any
  regression would be due to bugs in the compiler which would be good to
  catch anyway.

  
  Original bug report below:

  The multilib setup is not working in the bionic version of gcc-arm-
  none-eabi (gcc v6.3.1). For example, if I build a project with
  "-mcpu=cortex-m4" or "-march=armv7e-m" and link with:

  arm-none-eabi-gcc -o someoutput.elf  object1.o object2.o -mthumb -Wl
  ,--gc-sections -ffast-math -march=armv7-m -Tlinker_script.ld

  I get as output:

  /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/bin/ld: error: /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/crt0.o: Conflicting CPU architectures 13/1
  /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/bin/ld: failed to merge target specific data of file /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/crt0.o

  arm-none-eabi-readelf -A on any of my object files produces:

  Attribute Section: aeabi
  File Attributes
    Tag_CPU_name: "Cortex-M4"
    Tag_CPU_arch: v7E-M
    Tag_CPU_arch_profile: Microcontroller
    Tag_THUMB_ISA_use: Thumb-2
    Tag_ABI_PCS_wchar_t: 4
    Tag_ABI_FP_number_model: Finite
    Tag_ABI_align_needed: 8-byte
    Tag_ABI_align_preserved: 8-byte, except leaf SP
    Tag_ABI_enum_size: small
    Tag_ABI_optimization_goals: Prefer Speed
    Tag_CPU_unaligned_access: v6

  But "arm-none-eabi-readelf -A /usr/lib/gcc/arm-none-eabi/6.3.1
  /../../../arm-none-eabi/lib/crt0.o" gives

  Attribute Section: aeabi
  File Attributes
    Tag_CPU_arch: v4
    Tag_ARM_ISA_use: Yes

  If I define "void _init(void){}" and use -nostartfiles, compilation
  finishes but the resulting binary does not work. I have not examined
  the output file but it appears that it has somehow linked to code
  containing ARM as well as thumb code:

  # readelf -A someoutput.elf
  Attribute Section: aeabi
  File Attributes
    Tag_CPU_name: "Cortex-M4"
    Tag_CPU_arch: v7E-M
    Tag_CPU_arch_profile: Microcontroller
    Tag_ARM_ISA_use: Yes
    Tag_THUMB_ISA_use: Thumb-2
    Tag_ABI_PCS_wchar_t: 4
    Tag_ABI_FP_denormal: Needed
    Tag_ABI_FP_exceptions: Needed
    Tag_ABI_FP_number_model: IEEE 754
    Tag_ABI_align_needed: 8-byte
    Tag_ABI_align_preserved: 8-byte, except leaf SP
    Tag_ABI_enum_size: small
    Tag_ABI_optimization_goals: Prefer Speed
    Tag_CPU_unaligned_access: v6

  I can work around the problem by manually specifying compatible
  versions of libc and libgcc with -nostdlib:

  -nostdlib /usr/lib/arm-none-eabi/newlib/thumb/libc.a /usr/lib/gcc/arm-
  none-eabi/6.3.1/thumb/v7e-m/libgcc.a

  This produces a working binary. However, there is still something
  wrong because readelf -A still includes "Tag_ARM_ISA_use: Yes":

  Attribute Section: aeabi
  File Attributes
    Tag_CPU_name: "Cortex-M4"
    Tag_CPU_arch: v7E-M
    Tag_CPU_arch_profile: Microcontroller
    Tag_ARM_ISA_use: Yes
    Tag_THUMB_ISA_use: Thumb-2
    Tag_ABI_PCS_wchar_t: 4
    Tag_ABI_FP_denormal: Needed
    Tag_ABI_FP_exceptions: Needed
    Tag_ABI_FP_number_model: IEEE 754
    Tag_ABI_align_needed: 8-byte
    Tag_ABI_align_preserved: 8-byte, except leaf SP
    Tag_ABI_enum_size: small
    Tag_ABI_optimization_goals: Prefer Speed
    Tag_CPU_unaligned_access: v6

  Previously, using xenial and gcc v4, readelf gives the following output on the output binary:
  Attribute Section: aeabi
  File Attributes
    Tag_CPU_name: "7E-M"
    Tag_CPU_arch: v7E-M
    Tag_CPU_arch_profile: Microcontroller
    Tag_THUMB_ISA_use: Thumb-2
    Tag_ABI_PCS_wchar_t: 4
    Tag_ABI_FP_denormal: Needed
    Tag_ABI_FP_exceptions: Needed
    Tag_ABI_FP_number_model: IEEE 754
    Tag_ABI_align_needed: 8-byte
    Tag_ABI_enum_size: small
    Tag_ABI_optimization_goals: Prefer Speed
    Tag_CPU_unaligned_access: v6

  (Also, what happened to gdb-arm-none-eabi?)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/newlib/+bug/1767223/+subscriptions



More information about the Ubuntu-sponsors mailing list