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 >
