https://sourceware.org/bugzilla/show_bug.cgi?id=26722
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
EF_ARM_EABI_VERSION == EF_ARM_EABI_UNKNOWN.
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
extensions?
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.
