x86: Indirect Jump Tables Not Properly Handled in ObjDiff

[ifarbod]

ObjDiff fails to correctly interpret x86 indirect jump tables when analyzing disassembly. The tool shows raw data instead of properly reconstructing the jump table structure. In the example provided, the indirect table at 0x3c and jump targets at 0x30 should be formatted as a proper switch-case jump table, but they appear as fragmented data and incorrect instructions.

There's another tool called reccmp, which may have hints on how to properly handle this here.
https://github.com/isledecomp/reccmp/blob/master/reccmp/isledecomp/compare/asm/instgen.py

I have attached 2 OBJ files with and without indirect tables.

indirect-switch-table.zip
https://decomp.me/scratch/JCkIS (example scratch)
https://godbolt.org/z/ET4W6K9z6

96   0:       mov       eax, [esp+0x4]
96   4:       add       eax, 0xfffffff4
96   7:       cmp       eax, 0x8
96   a:       ja        short 28 ~>
96   c:       movzx     eax, byte ptr [eax+3c] ~>
96   13:      jmp       dword ptr [eax*0x4+30] ~>
101  1a:   ~> fld       st, dword ptr [__real@42700000]
112  20:      ret       
105  21:   ~> fld       st, dword ptr [__real@41f00000]
112  27:      ret       
109  28:   ~> fld       st, dword ptr [__real@41600000]
112  2e:      ret       
112  2f:      nop       
112  30:   ~> .dword    1a ~>
112  34:      .dword    21 ~>
112  38:      .dword    28 ~>
112  3c:   ~> add       [edx], al
112  3e:      add       al, [edx]
112  40:      add       [eax], al
112  42:      add       al, [edx]
112  44:      (bad)     

How it could show up:

.L1:
    .dword    1A
    .dword    E1
    .dword    D3

.L2:
    .byte 0, 2, 2, 2
    .byte 0, 0, 2, 2
    .byte 1

cc. @tomsons26

[Tornamic]

yeah, please fix this bug