Created attachment 8023 [details] result of mep-elf gcc/xgcc -B gcc -S on "int main(void){return 0;}" mep-elf gas from binutils 2.25 is failing to compile the simplest assembly; simple test case attached. $ gdb --args ../cross-binutils/cross-binutils-2.25-1.x86_64/build/mep-elf/gas/.libs/as-new mep-ret0.s GNU gdb (GDB) 7.8 [snip] Reading symbols from mep-elf/gas/.libs/as-new...done. (gdb) r Starting program: mep-elf/gas/.libs/as-new mep-ret0.s [New Thread 15824.0x27bc] [New Thread 15824.0x3a54] Program received signal SIGSEGV, Segmentation fault. cgen_bitset_copy (mask=mask@entry=0x100000000) opcodes/cgen-bitset.c:152 152 newmask = cgen_bitset_create ((mask->length * 8) - 1); (gdb) bt #0 cgen_bitset_copy (mask=mask@entry=0x100000000) at opcodes/cgen-bitset.c:152 #1 0x000000010042e862 in mep_cgen_cpu_open (arg_type=<optimized out>, arg_type@entry=CGEN_CPU_OPEN_MACHS) at opcodes/mep-desc.c:6317 #2 0x0000000100424ee5 in md_begin () at gas/config/tc-mep.c:489 #3 0x000000010049fa41 in perform_an_assembly_pass (argv=0x60003aa90, argc=2) at gas/as.c:1082 #4 main (argc=2, argv=0x60003aa90) at gas/as.c:1226
I don't see the failure here. Are you picking up the wrong libopcodes.so?
(In reply to Alan Modra from comment #1) > I don't see the failure here. Are you picking up the wrong libopcodes.so? I built this with static libbfd/libopcodes. However, now that you mention it, I confirmed that it does not happen on Linux, which gave me a clue as to what to look for. In opcodes/mep-desc.c:mep_cgen_cpu_open() there is the following: va_start (ap, arg_type); while (arg_type != CGEN_CPU_OPEN_END) { switch (arg_type) { case CGEN_CPU_OPEN_ISAS : isas = va_arg (ap, CGEN_BITSET *); <======= break; case CGEN_CPU_OPEN_MACHS : machs = va_arg (ap, unsigned int); break; But in gas/config/tc-mep.c:md_begin(): /* Set the machine number and endian. */ gas_cgen_cpu_desc = mep_cgen_cpu_open (CGEN_CPU_OPEN_MACHS, 0, CGEN_CPU_OPEN_ENDIAN, target_big_endian ? CGEN_ENDIAN_BIG : CGEN_ENDIAN_LITTLE, CGEN_CPU_OPEN_ISAS, 0, <======= CGEN_CPU_OPEN_END); Because of the differences in MS Win64 ABI vs SysV ABI[1], this '0' doesn't get handled the same way on Cygwin (or presumably on MinGW64) as it does on Linux, and it results in picking up garbage from the stack (IIUC). Being specific with the varargs types here, particularly that one, seems to fix it. [1] https://sourceforge.net/p/mingw-w64/wiki2/MinGW%20x64%20Software%20convention/
Created attachment 8024 [details] Proposed patch Please consider this patch for master and the 2.25 branch.
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "gdb and binutils". The branch, master has been updated via 6fd9d738c04fd1dd1d73c08f8a384ea3c8a160ab (commit) from 5c294fee9abb6bb259519d9cf164c34b81b83312 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=6fd9d738c04fd1dd1d73c08f8a384ea3c8a160ab commit 6fd9d738c04fd1dd1d73c08f8a384ea3c8a160ab Author: Yaakov Selkowitz <yselkowi@redhat.com> Date: Thu Dec 25 21:25:38 2014 +1030 Don't pass unadorned zeros to varargs functions PR gas/17753 * config/tc-mep.c (md_begin): Specify types of vararg literals. ----------------------------------------------------------------------- Summary of changes: gas/ChangeLog | 5 +++++ gas/config/tc-mep.c | 4 ++-- 2 files changed, 7 insertions(+), 2 deletions(-)
The binutils-2_25-branch branch has been updated by Alan Modra <amodra@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=2aa59379e7a58585555aaa20e219f24efbd660cc commit 2aa59379e7a58585555aaa20e219f24efbd660cc Author: Yaakov Selkowitz <yselkowi@redhat.com> Date: Thu Dec 25 21:25:38 2014 +1030 Don't pass unadorned zeros to varargs functions PR gas/17753 * config/tc-mep.c (md_begin): Specify types of vararg literals.
Fixed