[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug gas/26722] New: arm-unknown-elf sets inconsistent ELF OSABI values

From: jozef.l at mittosystems dot com
Subject: [Bug gas/26722] New: arm-unknown-elf sets inconsistent ELF OSABI values
Date: Fri, 09 Oct 2020 10:42:42 +0000


            Bug ID: 26722
           Summary: arm-unknown-elf sets inconsistent ELF OSABI values
           Product: binutils
           Version: 2.36 (HEAD)
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gas
          Assignee: unassigned at sourceware dot org
          Reporter: jozef.l at mittosystems dot com
  Target Milestone: ---

When assembling an SHF_GNU_MBIND section for arm-unknown-elf,
gas/config/obj-elf.c:obj_elf_section will set
elf_backend_data->elf_osabi to ELFOSABI_GNU from ELFOSABI_NONE.

However, bfd/elf32-arm.c:elf32_arm_init_file_header will set
i_ehdrp->e_ident[EI_OSABI] to ELFOSABI_ARM for
This is the default for non-eabi ARM targets, such as arm-unknown-elf.

Is arm-unknown-elf a legacy target? Should it just always set the ELF
OSABI to ELFOSABI_ARM, thereby disabling any modern GNU ELF OSABI

Or should elf32_arm_init_file_header only set i_ehdrp->e_ident[EI_OSABI]
to ELFOSABI_ARM if elf_backend_data->elf_osabi is ELF_OSABI_NONE?

The following testcase exposes the problem:
  .section ".mbind.foo","adx",%progbits

  $ arm-unknown-elf-as armbug.s

  arm-unknown-elf-as: GNU_MBIND section is unsupported
  armbug.s: Assembler messages:
  armbug.s: Fatal error: can't close a.out: sorry, cannot handle this file

This error message is coming from bfd/elf.c
(_bfd_elf_final_write_processing), which is why the the file close error
appears. If GAS caught the error in obj_elf_section, then an error would
be emitted, but it wouldn't be fatal.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]