x86-64-branch-3 test case

[Jan Beulich <jbeulich at suse dot com>]

H.J.,

in the course of addressing bug 24546 I'd once again stumbled across
this test, and in particular its entirely wrong expectations (aiui):
The notation "jmp symbol" expresses a direct jump, not an indirect
one. Adding any kind of prefix should not alter this. And a near
branch ("jmp" doesn't stand for far ones in AT&T syntax) should in
no case then even become a far branch encoding. Imo the correct
course of action by the assembler would be to either warn about
and drop the bogus (in Intel64 mode) prefix, or keep it as benign,
but still emit a direct branch encoding with a 32-bit displacement.

Thoughts?

For background: These are the intended new templates:

// Intel Syntax remaining jmp instances.
jmp, 2, 0xea, None, 1, CpuNo64, JumpInterSegment|No_bSuf|No_sSuf|No_qSuf|No_ldSuf, { Imm16, Imm16|Imm32 }
jmp, 1, 0xff, 0x5, 1, 0, AMD64|Modrm|JumpAbsolute|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf, { Dword|Fword|Unspecified|BaseIndex }
jmp, 1, 0xff, 0x5, 1, Cpu64, Intel64|Modrm|JumpAbsolute|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf, { Dword|Fword|Tbyte|Unspecified|BaseIndex }
ljmp, 2, 0xea, None, 1, CpuNo64, JumpInterSegment|No_bSuf|No_sSuf|No_qSuf|No_ldSuf, { Imm16, Imm16|Imm32 }
ljmp, 1, 0xff, 0x5, 1, 0, AMD64|Modrm|JumpAbsolute|No_bSuf|No_sSuf|No_qSuf|No_ldSuf, { Unspecified|BaseIndex }
ljmp, 1, 0xff, 0x5, 1, Cpu64, Intel64|Modrm|JumpAbsolute|No_bSuf|No_sSuf|No_ldSuf, { Unspecified|BaseIndex }

It's the Cpu64 here which causes things to break: i386-gen infers
no Disp16 in this case from BaseIndex, and hence the Disp16
generated in i.types[0] won't match in Intel64 mode (but as said
above imo there shouldn't have been a match even before my
changes). And of course i386_displacement() has its own issues
when considering the case of us assuming (with a warning) an
indirect branch even when not indicated so by '*' if no better
match can be found.

I assume it goes without saying that once I make the Cpu64 case
work correctly here, and if not going the match-the-direct-jmp
route as suggested above, the match would then be with the near
indirect jmp (which right now doesn't match just because of it
having Cpu64 on its template, as per above). IOW the generated
code here will change no matter what.

Thanks, Jan