PowerPC: PPC_INS_BDZLA behaves like a relative branch

[PeterMatula]

According to PowerPC specification, bdzla (PPC_INS_BDZLA) is a bcla variant -- absolute branch. But it looks like Capstone (next branch) takes it as a relative branch -- PPC_OP_IMM operand value is address + imm instead of just imm.

The output of my Capstone dumper utility program (dumps everything capstone knows about an instruction) should be pretty self-explanatory:

$ capstone-dumper -a ppc -m 32 -e big -b 0x1000 -t "bdzla 0x1234"

Keystone input : bdzla 0x1234
Keystone output: 42 40 12 37 

Capstone version: 1024 (major: 4, minor: 0)

#0
        General info:
                id     :  34 (bdzla)
                addr   :  1000
                size   :  4
                bytes  :  42 40 12 37 
                mnem   :  bdzla
                op str :  0x2234
        Detail info:
                R regs :  2
                        10 (ctr)
                        205 (rm)
                W regs :  1
                        10 (ctr)
                groups :  0
        Architecture-dependent info:
                branch code :  PPC_BC_INVALID
                branch hint :  PPC_BH_INVALID
                update cr0  :  false
                op count    :  1

                        type   :  PPC_OP_IMM
                        imm    :  0x2234

Instruction is at 0x1000 and ASM operand is 0x1234, but Capstone operand is 0x2234. I think it should be 0x1234.

The same thing for bdnzla (PPC_INS_BDNZLA) seems to be ok (operand is 0x1234):

$ capstone-dumper -a ppc -m 32 -e big -b 0x1000 -t "bdnzla 0x1234"

Keystone input : bdnzla 0x1234
Keystone output: 42 00 12 37 

Capstone version: 1024 (major: 4, minor: 0)

#0
        General info:
                id     :  28 (bdnzla)
                addr   :  1000
                size   :  4
                bytes  :  42 00 12 37 
                mnem   :  bdnzla
                op str :  0x1234
        Detail info:
                R regs :  2
                        10 (ctr)
                        205 (rm)
                W regs :  1
                        10 (ctr)
                groups :  0
        Architecture-dependent info:
                branch code :  PPC_BC_INVALID
                branch hint :  PPC_BH_INVALID
                update cr0  :  false
                op count    :  1

                        type   :  PPC_OP_IMM
                        imm    :  0x1234

[PeterMatula]

I checked that problem is not with Keystone that I use to assemble text ASM -- Keystone could theoretically make a mistake and Capstone could be innocent. But it looks like bug is in Capstone.

ODA (The Online Disassembler) input:

42 40 12 37 42 00 12 37

ODA output:

bdzla 0x00001234
bdnzla 0x00001234

[aquynh]

latest code in "next" now outputs this. is there anything you want to comment on?

$ cstool ppc64be "42401237 42001237"   
 0  42 40 12 37  bdzla	0x1234
 4  42 00 12 37  bdnzla	0x1234

[PeterMatula]

I was a bit confused because cstool with the latest commit from next gave me the same results as you posted, but capstone-dumper still shows address 0x2234. I think that it is because capstone-dumper places instructions at address 0x1000, and cstool does not. Therefore, cstool hides the problem because it adds 0x0 to the immediate operand - it looks like nothing was added - i.e. it looks like an absolute branch.

I think the problem is still there - bdzla is an absolute branch and its operand should not be dependent on instruction's position. For example, the following two bdzla instructions should have the same operand 0x1234, the same as bdnzla instructions do:

Commit: 69e26b5

$ cstool -v
cstool for Capstone Disassembler, v5.0.0

$ cstool ppc64be "42401237 42001237 42401237 42001237"
 0  42 40 12 37  bdzla  0x1234
 4  42 00 12 37  bdnzla 0x1234
 8  42 40 12 37  bdzla  0x123c
 c  42 00 12 37  bdnzla 0x1234

ODA: https://onlinedisassembler.com/odaweb/y9wiqyoX/0

[aquynh]

yes BDZLA is absolute branch, fixed now.

actually you can pass the (optional) offset to cstool as the last argument, see below.

$ cstool ppc64be "42401237 42001237 42401237 42001237" 1000
1000  42 40 12 37  bdzla	0x1234
1004  42 00 12 37  bdnzla	0x1234
1008  42 40 12 37  bdzla	0x1234
100c  42 00 12 37  bdnzla	0x1234

[PeterMatula]

Thank you, it is OK now.

Should I close it or leave it be until it gets merged to master?

[aquynh]

i will merge "next" into "master" when we are ready for v5 release. that will take some time.

[Rot127]

Closed with #2013
It is decoded as bcla, but the bo field can be used to distinguish them.