https://sourceware.org/bugzilla/show_bug.cgi?id=17753
--- Comment #2 from Cygwin/X maintainer <yselkowitz at cygwin dot com> ---
(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/
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
