public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: Doug Evans <dje@sebabeach.org> To: gcc-bugs@gcc.gnu.org, binutils@sources.redhat.com Subject: arm-elf snafu? can't mix default-soft-float, explicit -msoft-float Date: Tue, 22 Jul 2003 17:11:00 -0000 [thread overview] Message-ID: <20030722171600.A3F84B53E@mail.sebabeach.org> (raw) I found this while testing gcc with arm-elf-sid. Running /samantha/gnu-pure/gcc/gcc/testsuite/gcc.c-torture/execute/execute.exp ... Executing on host: /samantha/gnu-pure/b-arm-gcc/gcc/xgcc -B/samantha/gnu-pure/b-arm-gcc/gcc/ -c -msoft-float -o /samantha/gnu-pure/b-arm-gcc/gcc/testsuite/gcc-testglue.o /samantha/gnu-pure/gcc/gcc/../dejagnu/testglue.c (timeout = 300) Executing on host: /samantha/gnu-pure/b-arm-gcc/gcc/xgcc -B/samantha/gnu-pure/b-arm-gcc/gcc/ /samantha/gnu-pure/gcc/gcc/testsuite/gcc.c-torture/execute/20000112-1.c gcc_tg.o -w -O0 -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm -msoft-float -o /samantha/gnu-pure/b-arm-gcc/gcc/testsuite/20000112-1.x0 (timeout = 300) /samantha/gnu-pure/rel/lib/gcc-lib/arm-elf/3.4/../../../../arm-elf/bin/ld: ERROR: /samantha/gnu-pure/rel/lib/gcc-lib/arm-elf/3.4/../../../../arm-elf/lib/libc.a(atexit.o) uses hardware FP, whereas /samantha/gnu-pure/b-arm-gcc/gcc/testsuite/20000112-1.x0 uses software FP File format not recognized: failed to merge target specific data of file /samantha/gnu-pure/rel/lib/gcc-lib/arm-elf/3.4/../../../../arm-elf/lib/libc.a(atexit.o) /samantha/gnu-pure/rel/lib/gcc-lib/arm-elf/3.4/../../../../arm-elf/bin/ld: ERROR: /samantha/gnu-pure/rel/lib/gcc-lib/arm-elf/3.4/../../../../arm-elf/lib/libc.a(exit.o) uses hardware FP, whereas /samantha/gnu-pure/b-arm-gcc/gcc/testsuite/20000112-1.x0 uses software FP File format not recognized: failed to merge target specific data of file /samantha/gnu-pure/rel/lib/gcc-lib/arm-elf/3.4/../../../../arm-elf/lib/libc.a(exit.o) /samantha/gnu-pure/rel/lib/gcc-lib/arm-elf/3.4/../../../../arm-elf/bin/ld: ERROR: /samantha/gnu-pure/rel/lib/gcc-lib/arm-elf/3.4/../../../../arm-elf/lib/libc.a(impure.o) uses hardware FP, whereas /samantha/gnu-pure/b-arm-gcc/gcc/testsuite/20000112-1.x0 uses software FP File format not recognized: failed to merge target specific data of file /samantha/gnu-pure/rel/lib/gcc-lib/arm-elf/3.4/../../../../arm-elf/lib/libc.a(impure.o) [...] CVS source as of July 13. target=arm-elf NOTE: arm-elf defaults to -msoft-float. In gcc/config/arm/elf.h: #define TARGET_DEFAULT (ARM_FLAG_SOFT_FLOAT | ARM_FLAG_APCS_32 | ARM_FLAG_APCS_FRAME) Simple testcase: bash$ rm foo1.c foo2.c ; touch foo1.c foo2.c bash$ arm-elf-gcc -c foo1.c bash$ arm-elf-objdump -p foo1.o foo1.o: file format elf32-littlearm private flags = 0: [APCS-32] [FPA float format] bash$ arm-elf-gcc -c foo2.c -msoft-float foo1.o: file format elf32-littlearm private flags = 200: [APCS-32] [FPA float format] [software FP] bash$ arm-elf-gcc -nostdlib foo1.o foo2.o [links successfully] bash$ arm-elf-gcc -nostdlib foo2.o foo1.o /samantha/gnu-pure/rel/lib/gcc-lib/arm-elf/3.4/../../../../arm-elf/bin/ld: ERROR: foo1.o uses hardware FP, whereas a.out uses software FP File format not recognized: failed to merge target specific data of file foo1.o This line in gcc/config/arm/elf.h #ifndef SUBTARGET_ASM_FLOAT_SPEC #define SUBTARGET_ASM_FLOAT_SPEC "\ %{mapcs-float:-mfloat} %{msoft-float:-mfpu=softfpa}" #endif is causing an explicit -msoft-float to pass -mfpu=softfpa to gas which in turn causes EF_ARM_SOFT_FLOAT to be added to the elf e_flags field. That doesn't happen when -msoft-float is elided. [Ergo gas and/or ld had better default to that ... OTOH, propagating assumptions of default values throughout the tools is a pain. Better to restrict it to gcc.] Specifying the order as foo1.o foo2.o works whereas foo2.o foo1.o doesn't because in the former way there's no file after foo2.o for elf32_arm_merge_private_bfd_data to complain about. if ((in_flags & EF_ARM_SOFT_FLOAT) != (out_flags & EF_ARM_SOFT_FLOAT)) { /* We can allow interworking between code that is VFP format layout, and uses either soft float or integer regs for passing floating point arguments and results. We already know that the APCS_FLOAT flags match; similarly for VFP flags. */ if ((in_flags & EF_ARM_APCS_FLOAT) != 0 || (in_flags & EF_ARM_VFP_FLOAT) == 0) { if (in_flags & EF_ARM_SOFT_FLOAT) _bfd_error_handler (_("\ ERROR: %s uses software FP, whereas %s uses hardware FP"), bfd_archive_filename (ibfd), bfd_get_filename (obfd)); else _bfd_error_handler (_("\ ERROR: %s uses hardware FP, whereas %s uses software FP"), bfd_archive_filename (ibfd), bfd_get_filename (obfd)); flags_compatible = FALSE; } } Seems to me the first bug is that include/elf/arm.h:EF_ARM_* is over-specified thus allowing this implicit-default vs explicit-default mismatch to occur. [Obviously this is something that presumably can't be fixed though. Am I misreading the intention here?] /* Processor specific flags for the ELF header e_flags field. */ #define EF_ARM_RELEXEC 0x01 #define EF_ARM_HASENTRY 0x02 #define EF_ARM_INTERWORK 0x04 #define EF_ARM_APCS_26 0x08 #define EF_ARM_APCS_FLOAT 0x10 #define EF_ARM_PIC 0x20 #define EF_ARM_ALIGN8 0x40 /* 8-bit structure alignment is in use. */ #define EF_ARM_NEW_ABI 0x80 #define EF_ARM_OLD_ABI 0x100 #define EF_ARM_SOFT_FLOAT 0x200 #define EF_ARM_VFP_FLOAT 0x400 #define EF_ARM_MAVERICK_FLOAT 0x800 My preference for fixing this is to have gcc pass -mfpu=softfpa in the default case. Due to the way gcc is designed that can get a bit hairy though. Thus the second choice is to have gas have defaults that match gcc (then elf files have an unambiguous meaning of e_flags == 0). Failing that I guess elf32_arm_merge_private_bfd_data is going to have to become default aware. Suggestions?
next reply other threads:[~2003-07-22 17:11 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2003-07-22 17:11 Doug Evans [this message] 2003-07-23 18:35 ` Nick Clifton
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20030722171600.A3F84B53E@mail.sebabeach.org \ --to=dje@sebabeach.org \ --cc=binutils@sources.redhat.com \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).