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
