In pratical terms, if your binary was compiled with Sun Studio C++ then
the mangled name will match with the regexp __1.*Tug.*Initialize.*
So you can search this regexp into the symbol table to retrieve
the mangle name corresponding to your function and then disassemble it.

Example: I have want to dissamble the function refcount::initialize()

- lookup the mangle name into symbol table:

 > ::nm ! grep refcount.*initialize
0x000000007b6bc31c|0x000000000000010c|FUNC |GLOB |0x0  |1       
|__1cIrefcountOinitialize_int6M_i_
0x000000007b6bc278|0x000000000000005c|FUNC |GLOB |0x0  |1       
|__1cIrefcountKinitialize6F_i_

- check the name we are looking for:

 > ::dem __1cIrefcountKinitialize6F_i_
__1cIrefcountKinitialize6F_i_ == int refcount::initialize

- dissamble the function:

 > $G
C++ symbol demangling enabled

 > __1cIrefcountKinitialize6F_i_::dis
int refcount::initialize:       save      %sp, -0xb0, %sp
int refcount::initialize+4:     sethi     %hi(0xbc00), %i5
int refcount::initialize+8:     sethi     %hi(0x7021e400), %i1
int refcount::initialize+0xc:   call      -0x7a2bf86c   <void*operator new>
int refcount::initialize+0x10:  add       %i5, 0x108, %o0
int refcount::initialize+0x14:  call      -0x15c        <refcount::refcount 
#Nvariant 1>
int refcount::initialize+0x18:  mov       %o0, %i2


Note that it is a bit more tricky to dump constructors, destructors or
operators (+, =, ...) because they have a special encoding.


alex.

Michael Shapiro wrote:
>><address>$<bufctl_audit  (Produces typical stack)
>>
>>.....
>>void Tug::Initialize+0x28cc
>>main+0x2f4
>>_start+0x108
>>
>>
>>>main::dis (Works as expected....)
>>>Tug::Initialize::dis <---(Obviously not gonna work!)
>>
>>What's correct syntax to disassemble Tug::Initialize?
> 
> 
> There is no support in mdb for C++ (or any non-C language) symbols: you have
> to specify the mangled form.  This is in part because there is no generic
> mangling routine offered by the compilers -- there is only demangling.  If you
> want to do the above, mdb need to get much further in bed with a particular
> compiler, which is one of the places we've thus far avoiding going.
> 
> -Mike
>  

Reply via email to