Bug 485319 - Add support for new Power7 instructions
Summary: Add support for new Power7 instructions
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: gdb
Version: rawhide
Hardware: powerpc
OS: Linux
low
medium
Target Milestone: ---
Assignee: Jan Kratochvil
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-02-12 20:37 UTC by Thiago Jung Bauermann
Modified: 2009-04-05 21:04 UTC (History)
4 users (show)

Fixed In Version: 6.8.50.20090302-15.fc11
Clone Of:
Environment:
Last Closed: 2009-04-05 21:04:58 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Fix power7 ppc64 recognization. (2.10 KB, patch)
2009-03-02 15:41 UTC, Jan Kratochvil
no flags Details | Diff

Description Thiago Jung Bauermann 2009-02-12 20:37:05 UTC
Description of problem:

A patch supporting new Power7 instructions will be submitted to binutils (and probably committed) in the next few days. The patch should find its way into Fedora 11's Archer/GDB so that it can disassemble those instructions.

Version-Release number of selected component (if applicable):


How reproducible:

Always

Steps to Reproduce:
1. Compile a binary with new power7 instructions.
2. Use GDB's disassemble command on the binary.
3. Verify that a power7 instruction is properly disassembled.
  
Actual results:

A string similar to "long 0xdeadbeef" will be shown instead of the actual instruction mnemonic and arguments.

Expected results:

The correct instruction mnemonic and its arguments should be shown.

Additional info:

Comment 1 Peter Bergner 2009-02-28 20:33:50 UTC
The Full POWER7 binutils support has been committed upstream.  However, it seems GDB seems to only have a partial merge of the relevant binutils code, so this cannot be applied as is.  Maybe GDB sources could just re-merge the code from binutils?  Anyway, here is the patch that added Full POWER7 binutils support.
Note that there was an earlier Initial POWER7 patched committed to binutils and it is that patch that GDB only seems to have partially merged.

    http://sourceware.org/ml/binutils/2009-02/msg00354.html

Comment 2 Jan Kratochvil 2009-03-02 15:41:42 UTC
Created attachment 333750 [details]
Fix power7 ppc64 recognization.

On the binary from:
./gas/as-new -mpower7 -o /tmp/power7c.o ./gas/testsuite/gas/ppc/power7.s
  Class:                             ELF64
  Machine:                           PowerPC64
Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 4] .PPC.EMB.apuinfo  PROGBITS         0000000000000000  000001e0
       0000000000000018  0000000000000000           0     0     1

FSF GDB HEAD prints:
$ ./gdb -q -nx -ex 'set pagination off' -ex 'x/100i 0' /tmp/power7.o  </dev/null 
Architecture of file not recognized.
0x0:	Cannot access memory at address 0x0
(gdb) quit

With the attached patch it prints the dump below.

Patch header:
It is a regression for power7 ppc64 binaries by:
http://sourceware.org/ml/gdb-patches/2002-08/threads.html#00629
http://sourceware.org/ml/gdb-cvs/2002-08/msg00263.html

> A powerpc executable doesn't have indications of which variant it is meant to
> run on.
There is the tdesc_* infrastructure for this purpose for remote targets, there
is a `info->disassembler_options = "any"' hack for local target by:
http://sourceware.org/ml/gdb-patches/2007-02/msg00000.html
http://sourceware.org/ml/gdb-cvs/2007-02/msg00061.html

        Fix power7 ppc64 binaries recognization.
        * rs6000-tdep.c (rs6000_gdbarch_init): Remove variable `sect'.  Remove
        the ppc32 e500 detection by `.PPC.EMB.apuinfo' existence.

Going to post it upstream, assuming IBM agrees with it.


(no debugging symbols found)
0x0 <power7>:	lxvd2x  vs3,r4,r5
0x4 <power7+4>:	lxvd2ux vs3,r4,r5
0x8 <power7+8>:	lxvd2x  vs43,r4,r5
0xc <power7+12>:	lxvd2ux vs43,r4,r5
0x10 <power7+16>:	stxvd2x vs3,r4,r5
0x14 <power7+20>:	stxvd2ux vs3,r4,r5
0x18 <power7+24>:	stxvd2x vs43,r4,r5
0x1c <power7+28>:	stxvd2ux vs43,r4,r5
0x20 <power7+32>:	stfq    f3,10320(r4)
0x24 <power7+36>:	stfq    f11,26711(r12)
0x28 <power7+40>:	stfq    f3,11088(r4)
0x2c <power7+44>:	stfq    f11,27479(r12)
0x30 <power7+48>:	stfq    f3,10320(r4)
0x34 <power7+52>:	stfq    f11,26711(r12)
0x38 <power7+56>:	stfq    f3,11088(r4)
0x3c <power7+60>:	stfq    f11,27479(r12)
0x40 <power7+64>:	stfq    f3,10576(r4)
0x44 <power7+68>:	stfq    f11,26967(r12)
0x48 <power7+72>:	stfq    f3,10832(r4)
0x4c <power7+76>:	stfq    f11,27223(r12)
0x50 <power7+80>:	stfq    f3,10112(r4)
0x54 <power7+84>:	stfq    f11,26503(r12)
0x58 <power7+88>:	stfq    f3,10112(r4)
0x5c <power7+92>:	stfq    f11,26503(r12)
0x60 <power7+96>:	stfq    f3,12160(r4)
0x64 <power7+100>:	stfq    f11,28551(r12)
0x68 <power7+104>:	wait    
0x6c <power7+108>:	wait    
0x70 <power7+112>:	waitrsv
0x74 <power7+116>:	waitrsv
0x78 <power7+120>:	waitimpl
0x7c <power7+124>:	waitimpl
0x80 <power7+128>:	doze
0x84 <power7+132>:	nap
0x88 <power7+136>:	sleep
0x8c <power7+140>:	rvwinkle
0x90 <power7+144>:	prtyw   r3,r4
0x94 <power7+148>:	prtyd   r13,r14
0x98 <power7+152>:	mfspr   r10,28
0x9c <power7+156>:	mtspr   28,r11
0xa0 <power7+160>:	cmpb    r3,r4,r5
0xa4 <power7+164>:	lwzcix  r10,r11,r12
0xa8 <power7+168>:	dadd    f16,f17,f18
0xac <power7+172>:	daddq   f20,f22,f24
0xb0 <power7+176>:	dss     3
0xb4 <power7+180>:	dssall
0xb8 <power7+184>:	dst     r5,r4,1
0xbc <power7+188>:	dstt    r8,r7,0
0xc0 <power7+192>:	dstst   r5,r6,3
0xc4 <power7+196>:	dststt  r4,r5,2
0xc8 <power7+200>:	divwe   r10,r11,r12
0xcc <power7+204>:	divwe.  r11,r12,r13
0xd0 <power7+208>:	divweo  r12,r13,r14
0xd4 <power7+212>:	divweo. r13,r14,r15
0xd8 <power7+216>:	divweu  r10,r11,r12
0xdc <power7+220>:	divweu. r11,r12,r13
0xe0 <power7+224>:	divweuo r12,r13,r14
0xe4 <power7+228>:	divweuo. r13,r14,r15
0xe8 <power7+232>:	bpermd  r7,r17,r27
0xec <power7+236>:	popcntw r10,r20
0xf0 <power7+240>:	popcntd r10,r20
0xf4 <power7+244>:	ldbrx   r20,r21,r22
0xf8 <power7+248>:	stdbrx  r20,r21,r22
0xfc <power7+252>:	lfiwzx  f10,0,r10
0x100 <power7+256>:	lfiwzx  f10,r9,r10
0x104 <power7+260>:	fcfids  f4,f5
0x108 <power7+264>:	fcfids. f4,f5
0x10c <power7+268>:	fcfidus f4,f5
0x110 <power7+272>:	fcfidus. f4,f5
0x114 <power7+276>:	fctiwu  f4,f5
0x118 <power7+280>:	fctiwu. f4,f5
0x11c <power7+284>:	fctiwuz f4,f5
0x120 <power7+288>:	fctiwuz. f4,f5
0x124 <power7+292>:	fctidu  f4,f5
0x128 <power7+296>:	fctidu. f4,f5
0x12c <power7+300>:	fctiduz f4,f5
0x130 <power7+304>:	fctiduz. f4,f5
0x134 <power7+308>:	fcfidu  f4,f5
0x138 <power7+312>:	fcfidu. f4,f5
0x13c <power7+316>:	ftdiv   cr0,f10,f11
0x140 <power7+320>:	ftdiv   cr7,f10,f11
0x144 <power7+324>:	ftsqrt  cr0,f10
0x148 <power7+328>:	ftsqrt  cr7,f10
0x14c <power7+332>:	dcbt    16,r8,r9
0x150 <power7+336>:	dcbtst  16,r8,r9
0x154 <power7+340>:	dcffix  f10,f12
0x158 <power7+344>:	dcffix. f20,f22
0x15c <power7+348>:	lbarx   r10,r11,r12
0x160 <power7+352>:	lbarx   r10,r11,r12
0x164 <power7+356>:	lbarx   r10,r11,r12,1
0x168 <power7+360>:	lharx   r20,r21,r22
0x16c <power7+364>:	lharx   r20,r21,r22
0x170 <power7+368>:	lharx   r20,r21,r22,1
0x174 <power7+372>:	stbcx.  r10,r11,r12
0x178 <power7+376>:	sthcx.  r10,r11,r12
0x17c <power7+380>:	fre     f14,f15
0x180 <power7+384>:	fre.    f14,f15
0x184 <power7+388>:	fres    f14,f15
0x188 <power7+392>:	fres.   f14,f15
0x18c <power7+396>:	frsqrte f14,f15
(gdb) quit

Comment 3 Jan Kratochvil 2009-03-02 21:06:53 UTC
Archer [archer-jankratochvil-misc] commits:
dbdbd032f965ce2d447859f2ea15dfd8d488f268
b83458acdef987da786ffd02a312cb8b8ca2a6ea

FSF GDB post:
http://sourceware.org/ml/gdb-patches/2009-03/msg00019.html
http://sourceware.org/ml/gdb-patches/2009-03/msg00020.html

Comment 4 Jan Kratochvil 2009-03-30 19:32:42 UTC
As in FSF binutils remains this bug:
$ ./gas/as-new -o power7.o -mpower7 ./gas/testsuite/gas/ppc/power7.s
$ ./binutils/objdump -d -Many power7.o >d-any
$ ./binutils/objdump -d -Mpower7 power7.o >d-power7
$ diff -u d-any d-power7
-  98:  7d 5c 02 a6     mfspr   r10,28
+  98:  7d 5c 02 a6     mfcfar  r10
-  9c:  7d 7c 03 a6     mtspr   28,r11
+  9c:  7d 7c 03 a6     mtcfar  r11
- 14c:  7e 08 4a 2c     dcbt    16,r8,r9
+ 14c:  7e 08 4a 2c     dcbtt   r8,r9
- 150:  7e 08 49 ec     dcbtst  16,r8,r9
+ 150:  7e 08 49 ec     dcbtstt r8,r9

checked-in 4 KFAILs for it and GDB currently disassembles the wrong form of them.
There is currently no way how to force -Mpower7 in GDB:

* Mon Mar 30 2009 Jan Kratochvil <jan.kratochvil> - 6.8.50.20090302-13
- Archer update to the snapshot: d144a3633454046aaeae3e2c369c271834431d36
[...]
- Archer backport: fe48224ce1bd22f37a7fa6d111d54c1a340392bf
  - KFAIL 4 cases of: gdb.arch/powerpc-power7.exp

Comment 5 Peter Bergner 2009-04-01 22:32:18 UTC
I'm working on one more patch.  However, -Many will never give the exact same output as -M<cpu> for all valid <cpu> values, but this should work for the majority of <cpu> values (eg, power7, power6, power5, power4, 970, etc.).

Comment 6 Peter Bergner 2009-04-01 22:36:49 UTC
Adding Alan for comment, once I post the patch to the binutils mailing list.  If we don't like the resulting patch (hopefully posted tonight or tomorrow morning), then we can close this again.

Comment 7 Peter Bergner 2009-04-02 13:34:01 UTC
Ok, I committed the following patch this morning:

    http://sourceware.org/ml/binutils/2009-04/msg00052.html

Jan, how does the disassembly look now?

Comment 8 Jan Kratochvil 2009-04-05 21:04:58 UTC
Yes, it works fine now, thanks.
Removed the KFAIL workaround there, it all PASSes now.

* Sun Apr  5 2009 Jan Kratochvil <jan.kratochvil> - 6.8.50.20090302-15
- Archer update to the snapshot: 7c7c77576669d17ad5072daa47ea3a4fd954483d
- Archer backport: 7c7c77576669d17ad5072daa47ea3a4fd954483d (Peter Bergner)
  - Disassemble Power7 instructions right in the default/only -Many GDB mode.


Note You need to log in before you can comment on or make changes to this bug.