binutils bug? jecxz gets one 0x67 prefix too many on MIC

[Mikael_P_]

I'm using the MIC GNU toolchain (extracted from KNC_beta-2.1.3653-8-rhel-6.2.tgz) to port some system software to Intel MIC. The assembler appears to be a modified binutils-2.22.52.20120302 snapshot. I've noticed that assembling a "jecxz" results in not one 0x67 prefix as expected, but two 0x67 prefixes, which I believe is technically invalid (though the HW seems to swallow it).

> cat jecxz.s
.text
.globl foo
foo:
        jecxz 1f
1:      ret
> /usr/linux-k1om-4.7/bin/x86_64-k1om-linux-as -o jecxz.o jecxz.s
> /usr/linux-k1om-4.7/bin/x86_64-k1om-linux-objdump -d jecxz.o

jecxz.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <foo>:
   0:   67 67 e3 00             addr64 jecxz 4 <foo+0x4>
   4:   c3                      retq   

A plain vanilla binutils-2.22 does not generate the extra 0x67 prefix when assembling with --march=k1om.

/Mikael

[BelindaLiviero]

can you see if the issue is reproducible against the latest: http://registrationcenter.intel.com/irc_nas/2892/KNC_gold-2.1.4346-16-rhel-6.2.gz

[Mikael_P_]

Yes, the "usr/linux-k1om-4.7/bin/x86_64-k1om-linux-as" in KNC_gold-2.1.4346-16 also generates the double 0x67 prefix for jecxz.

[BelindaLiviero]

thank you for reporting this -- the bug was reproduced internally...as soon as I hear back from the developers on a fix I will reply back to this thread with a timeline

[Mikael_P_]

For the record, this bug is now known to originate from the upstream binutils sources, and it's since been fixed there. See PR gas/14859 over at sourceware.org's bugzilla for details.

[BelindaLiviero]

Seems that the bug fix has propagated, our latest test (and with the latest MPSS http://software.intel.com/en-us/articles/intel-manycore-platform-software-stack-mpss) aren't showing this problem any longer