Thanks Ed for pointing to the bug that refers to the same problem that i am experiencing. I did ::dismod v9plus to enable, and could now see the mnemonics...Here it is:
> ::dismode v9plus disassembly mode is v9plus (UltraSPARC1-v9 disassembler) > libc_psr.so.1`memcpy+0x3d4::dis libc_psr.so.1`memcpy+0x3ac: be,pt %icc, +0x68 <libc_psr.so.1`memcpy+0x414> libc_psr.so.1`memcpy+0x3b0: sub %o2, %o5, %o2 libc_psr.so.1`memcpy+0x3b4: ldd [%o1], %f2 libc_psr.so.1`memcpy+0x3b8: subcc %o5, 8, %o5 libc_psr.so.1`memcpy+0x3bc: be,pn %icc, +0x38 <libc_psr.so.1`memcpy+0x3f4> libc_psr.so.1`memcpy+0x3c0: add %o1, 8, %o1 libc_psr.so.1`memcpy+0x3c4: faligndata %f0, %f2, %f4 libc_psr.so.1`memcpy+0x3c8: ldd [%o1], %f0 libc_psr.so.1`memcpy+0x3cc: subcc %o5, 8, %o5 libc_psr.so.1`memcpy+0x3d0: add %o1, 0x10, %o1 libc_psr.so.1`memcpy+0x3d4: std %f4, [%o0] libc_psr.so.1`memcpy+0x3d8: be,pn %icc, +0x30 <libc_psr.so.1`memcpy+0x408> libc_psr.so.1`memcpy+0x3dc: faligndata %f2, %f0, %f6 libc_psr.so.1`memcpy+0x3e0: ldd [%o1 - 8], %f2 libc_psr.so.1`memcpy+0x3e4: subcc %o5, 8, %o5 libc_psr.so.1`memcpy+0x3e8: std %f6, [%o0 + 8] libc_psr.so.1`memcpy+0x3ec: bne,pt %icc, -0x28 <libc_psr.so.1`memcpy+0x3c4> libc_psr.so.1`memcpy+0x3f0: add %o0, 0x10, %o0 libc_psr.so.1`memcpy+0x3f4: faligndata %f0, %f2, %f4 As Greg rightly pointed out, these are indeed branch (with prediction) instructions.. Cheers --Arindam Edward Pilatowicz wrote: >your guess is correct. >this actually tripped me up recently and i was pointed to the >following bug: > 4884128 ::dis should default to each object's native mode > >which mentions that you can enable dissassembly of the v9 >instructions in mdb with the following command: > ::dismode v9plus > >ed > > >On Mon, Jul 16, 2007 at 09:30:28PM +1000, Greg Price wrote: > > >>These instructions are branches with prediction, i.e. SPARC v9 >>instructions. I suspect the disassemblers only display instructions they >>think are legitimate for the target code. In this case it's a 32-bit >>program, hence it's not SPARC v9, and the disassembler has decided it >>won't decode the v9 instructions. The reason why we have v9 instructions >>is this is an optimized platform specific library that will only be >>loaded for relevant platforms - in this case the 480R loads the Sun4u / >>UltraSPARC III library as the system knows it has UltraSPARC processors. >>SPARC v9 instructions are still legitimate instructions in a 32 bit >>program when running on an UltraSPARC (It's really only the address mode >>that changes when running "32 bit mode") >> >>That would be my guess. Make sense? >> >>Cheers, >>Greg >> >> >> >>Arindam Sarkar - Sun Microsystems wrote: >> >> >>>Hi, >>> I was looking at a userland core, where the tar program dumps core >>>when it calls mempcy() routine >>> of libc_psr library. The call to memcpy() is from a while loop, and >>>during an iteration tar dumps >>> core when it calls memcpy(). >>> While i was analysing the userland core, i found the following >>>after dumping the instructions at >>> libc_psr.so.1`memcpy+0x3d4. >>> >>> > libc_psr.so.1`memcpy+0x3d4::dis >>>libc_psr.so.1`memcpy+0x3ac: 0x248001a >>>libc_psr.so.1`memcpy+0x3b0: sub %o2, %o5, %o2 >>>libc_psr.so.1`memcpy+0x3b4: ldd [%o1], %f2 >>>libc_psr.so.1`memcpy+0x3b8: subcc %o5, 8, %o5 >>>libc_psr.so.1`memcpy+0x3bc: 0x240000e >>>libc_psr.so.1`memcpy+0x3c0: add %o1, 8, %o1 >>>libc_psr.so.1`memcpy+0x3c4: 0x89b00902 >>>libc_psr.so.1`memcpy+0x3c8: ldd [%o1], %f0 >>>libc_psr.so.1`memcpy+0x3cc: subcc %o5, 8, %o5 >>>libc_psr.so.1`memcpy+0x3d0: add %o1, 0x10, %o1 >>>libc_psr.so.1`memcpy+0x3d4: std %f4, [%o0] >>> >>> > !uname -a >>>SunOS line2-v480 5.10 Generic_120011-11 sun4u sparc SUNW,Sun-Fire-480R >>> > !cat /etc/release >>> Solaris 10 8/07 s10s_u4wos_10 SPARC >>> Copyright 2007 Sun Microsystems, Inc. All Rights Reserved. >>> Use is subject to license terms. >>> Assembled 21 June 2007 >>> > ::status >>>debugging core file of tar (32-bit) from line2-v480 >>>file: /usr/sbin/tar >>>initial argv: tar -xpf 10g.tar >>>threading model: multi-threaded >>>status: process terminated by SIGSEGV (Segmentation Fault) >>> >>> >>> I am not sure why do we see an address at libc_psr.so.1`memcpy+0x3bc, >>>instead of the usual mnemonic. >>> Note, this core dump is the result of reproducing a bug on a sparc >>>machine having S10U4. Can someone >>> pls tell me *why* we don't see the mnemonic for the 3 instructions in >>>the above output ? Pls respond to >>> me directly since i am not yet a member of this alias. >>> >>> >>> >>>TIA >>>--Arindam >>>_______________________________________________ >>>mdb-discuss mailing list >>>mdb-discuss at opensolaris.org >>> >>> >>> >>_______________________________________________ >>mdb-discuss mailing list >>mdb-discuss at opensolaris.org >> >>
