pdfj command emit signed address fields (jump, fail) as unsigned

[jay-waves]

Description

When using JSON output commands pdfj, fields like "jump" and "fail" — which are internally stored as signed 64-bit integers (int64_t) — are emitted as unsigned values in the resulting JSON. This causes negative offsets (e.g. for PC-relative calls or branches) to be incorrectly interpreted as very large positive integers in downstream tools.

Environment

target arch: sparc v8 32b

2025-6-16
radare2 5.9.8 1 @ windows-x86-64
birth: git.5.9.8 Tue 11/19/2024__11:46:03.42
commit: 4eb49d5ad8c99eaecc8850a2f10bad407067c898
options: gpl -O? cs:5 cl:1 meson

Test

r2 -a sparc -b 32 -m 0x40000000 xxx.bin

[.....]> pdfj @ 0x40423128
[
    ...
    {
      "offset": 1078079828,
      "esil": "",
      "refptr": 0,
      "fcn_addr": 1078079784,
      "fcn_last": 1078079848,
      "size": 4,
      "opcode": "call -0xe0814f0",
      "disasm": "call -0xe0814f0",
      "bytes": "6c6d6e6f",
      "family": "cpu",
      "type": "call",
      "reloc": false,
      "type_num": 3,
      "type2_num": 0,
      "jump": 18446744073474140944,  <-----?????? bigger than 0xffffffff
      "fail": 1078079836
    },
    ...
] 

[.....]> pdf @ 0x40423128
┌ 68: fcn.40423128 ();
      ...
      0x40423154      6c6d6e6f       call -0xe0814f0
      ...

[trufae]

Capstone reports a negative address because that's what it is. a call to an address that's before the current location.. but that offset is far below address zero, so it ends up showing a negative value in here.

If i recall correctly, what sparc32 does is wrapping around the address space to 32bit, so considering this should be reported and fixed in capstone, i just pushed a workaround towards this in master. But still. i assume this code is not correct or its located in kernel memory using a higher base address