Description of problem: The PowerPC AltiVec instruction vsplth v0,v0,0 // 0x1000024c is incorrectly disassembled by gdb as psq_lux f0,r0,r0,0,4 Version-Release number of selected component (if applicable): gdb-7.4.50.20120120-38.fc17.ppc How reproducible: always Steps to Reproduce: 1. Use "gcc -c vsplth.S" to compile the one instruction vsplth 0,0,0 // 0x1000024c 2. Disassemble using "gdb vsplth.o": (gdb) x/i 0 3. Actual results: 0x0: psq_lux f0,r0,r0,0,4 Expected results: 0x0: vsplth v0,v0,0 Additional info: Documentation is on p.245 of https://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/FBFA164F824370F987256D6A006F424D/$file/vector_simd_pem.ppc.2005AUG23.pdf
This is the output you get from: objdump -d -M any 1.o rs6000-tdep.c: /* When debugging E500 binaries and disassembling code containing E500-specific (SPE) instructions, one sometimes sees AltiVec instructions instead. The opcode spaces for SPE instructions and AltiVec instructions overlap, and specifiying the "any" cpu looks for AltiVec instructions first. If we know we're debugging an E500 binary, however, we can specify the "e500x2" cpu and get much more sane disassembly output. */ if (info->mach == bfd_mach_ppc_e500) info->disassembler_options = "e500x2"; else info->disassembler_options = "any"; So vsplth is AltiVec? It should be preferred according to the text above. Setting architecture somehow does not work for me: (gdb) set architecture auto powerpc:604 powerpc:750 powerpc:common powerpc:e500mc64 powerpc:rs64iii rs6000:rs1 [...] powerpc:rs64ii rs6000:6000 (gdb) set architecture rs6000:rs1 Architecture `rs6000:rs1' not recognized. The target architecture is set automatically (currently powerpc:common64)
Upstream apparently fixed it. I have not bisected the revision. http://ppc.koji.fedoraproject.org/koji/buildinfo?buildID=86661 GNU gdb (GDB) Fedora (7.4.50.20120603-2.fc18) This GDB was configured as "ppc64-redhat-linux-gnu". (gdb) x/i 0 0x0: vsplth v0,v0,0 It can be backported to F-17 upon request.