What do the numbers mean in a disassembled CALL instruction on SPARC?

Question

Analysing a core dump using mdb and dbx debuggers under SPARC Solaris.

mdb dis DCMD shows:

>fn_name+0x1cc::dis
lib.so`fn_name+0x1cc: call      +0xa92fc      <0xfafbc36c>

dbx dis command for the same address and the core file shows:

(dbx) dis fn_name+0x1cc
0xfaf1307c: fn_name+0x01cc:       call     _PROCEDURE_LINKAGE_TABLE_+0x15c0 [PLT] ! 0xfafbc350

(dbx) print _PROCEDURE_LINKAGE_TABLE_
_PROCEDURE_LINKAGE_TABLE_ = 0

---

What do +0xa92fc <0xfafbc36c> numbers in mdb mean?

What is 0xfafbc350 under dbx? (I guess 0x15c0 is an offset from _PROCEDURE_LINKAGE_TABLE_)

Is it normal that those are different?

Answer 1

I don't know either of those tools, but I can answer one part of this because they look similar to what gdb and other typical disassemblers show:

0xfafbc36c is the absolute destination; the disassembler conveniently calculates the branch target for you.

---

+0xa92fc is the relative offset in the machine instruction. Like almost all architectures, SPARC branch and call instructions use a relative displacement.

It's a 30-bit displacement left-shifted by 2, so it can reach any other word-aligned address, but it's still relative so position-independent code can work easily. If the same code was loaded at a different address, the +0x0xa92fc offset would be the same, but the absolute target would be different.

Regular branches only use 22-bit or smaller displacements, again left-shifted by 2.

Some quotes from the SPARCv8 ISA manual:

PC-relative CTI (Control Transfer Instruction)

A PC-relative CTI computes its target address by sign-extending its immediate field to 32 bits, left-shifting that word displacement by two bits to create a byte displacement, and adding the resulting byte displacement to the contents of the PC.

The 32-bit PC contains the address of the instruction currently being executed by the IU.

So unlike some other architectures (e.g. x86), branches are relative to the starting address of the branch instruction, not the end of the branch instruction / start of the next instruction.