Ghidra: disassembly error ARM:BE:32:v8T (1.103)

[pabx06]

Describe the bug
Disassemble (key-shortcut 'd'/'F11') stop disassembly with error . while IDA pro & onlinedisassembler works.
Unable to resolve constructor at 4046fec0 (flow from 4046febc)

Expected behavior
to disassemble

Screenshots
Ghidra:
Unable to resolve constructor at 4046fec0 (flow from 4046febc)

IDA PRO/onlinedisassembler :

Attachments
the function@4046fea8

f2 4f 62 80 f2 cc 22 d8 f2 0f 00 2c 60 d0 20 01 62 90 f6 40 60 c0 f2 c4 10 0b 64 d0 20 00 65 10

Environment (please complete the following information):

• OS: linux
• Java Version: 11
• Ghidra Version: master branch two weeks ago.

Additional context
Add any other context about the problem here.

[mumbel]

is that actually even code? that falls of into nowhere after the ANDCS looks like in your IDA screenshot, is the XREF actually a jump to that location (is is that blob after just weird and should have disassembled as well)? not sure what the point of the online screen shot is, looks like you chose the wrong endian maybe?

[astrelsky]

is that actually even code? that falls of into nowhere after the ANDCS looks like in your IDA screenshot, is the XREF actually a jump to that location (is is that blob after just weird and should have disassembled as well)? not sure what the point of the online screen shot is, looks like you chose the wrong endian maybe?

I don't think it is either. addvss pc, r0, 0x4000000 is a bit strange but even so it would result in a shared return call.

[pabx06]

is that actually even code? that falls of into nowhere after the ANDCS

it look like a convoluted jump table.

looks like you chose the wrong endian maybe?

oups my bad. onlinedissassembler screenshoot was wrong. USER interface doesn't work well for Endian.

Endian is BIG i assume it fine because i have like 120k functions in a 100M binary blob. 12 disassembly errors. and i reversed/recovered datatype so far 4 opensource lib openssl,zlib,gsoap,libexpat,spidermoneky,libpng and their code was consistent with their source code.

pretty sure BigEndian is fine...
However i have no idea about the Architecture versions, profiles, and variants...

is the XREF actually a jump to that location

yes there is a jump to FUN_4046fea8. from sub_4046ffde witch is referenced by what look like a Virtual pointer table:

it is unlikely that actual data was being disassembled in cascade. However i expected ghidra to be able to dissemble those bytes

searching the manual . i found this:
LDRD with cond=NE

So Witch one is wright/wrong? ?

[pabx06]

is that actually even code? that falls of into nowhere after the ANDCS looks like in your IDA screenshot, is the XREF actually a jump to that location (is is that blob after just weird and should have disassembled as well)? not sure what the point of the online screen shot is, looks like you chose the wrong endian maybe?

I don't think it is either. addvss pc, r0, 0x4000000 is a bit strange but even so it would result in a shared return call.

0x4000000 is start of valid address range

[mumbel]

those +1 mean thumb mode, maybe that didn't get picked up by either ida or ghidra, try disassemble thumb (f12 maybe?)

[pabx06]

@astrelsky do you think it is a VPTR ?

@mumbel yes: VPTR -> thumb mode function (+1) -> ARM mode

[pabx06]

look like BL to odd address dont switch to ARM MODE ??? bit stange why Tmode was set 0 while there is just one flow to it.
changing to tmode did the trick

[astrelsky]

@astrelsky do you think it is a VPTR ?

@mumbel yes: VPTR -> thumb mode function (+1) -> ARM mode

Follow the pointer at address 0x410b0ee4 from that address go down one pointer and follow the pointer there. If it points to a string then I would say that data structure is a vtable. If you know for certain the vptr in question is pointing to the start of that function table then I would say it is a vptr.

[pabx06]

solved

[pabx06]

@astrelsky do you think it is a VPTR ?
@mumbel yes: VPTR -> thumb mode function (+1) -> ARM mode

Follow the pointer at address 0x410b0ee4 from that address go down one pointer and follow the pointer there. If it points to a string then I would say that data structure is a vtable. If you know for certain the vptr in question is pointing to the start of that function table then I would say it is a vptr.

no string there . 0x410b0ee4 is a pointer to an array of 6 function pointer . those 6 pointer point at the start of what can be valid function prologue start.

i hade trouble unwrapping this structure: that is used some code that echo "loop in connection graph"/"node"/ and graph stuff

to

to

to

[astrelsky]

Oh. What language is it? It is most likely a wrapper or native implementation for another programming language.

If the program was written in C++ and compiled with either g++ or clang++ this would still apply. The pointer at 0x0x410b0eec would point to a typename. When I said down I meant an incrementing address and downward on the screen. That was my fault though as I should have been more clear.

For the gnu and clang compilers it is laid out as follows:

struct vtable {
    ptrdiff_t vbtable[]; // one for each public virtual base plus 1
    type_info *typeinfo;
    void (*vftable)[]; // _vptr points here
};
struct type_info {
    vtable *_vptr;
    const char *typename;
};

The pointer at 0x410b0ee4 should be the type_info * so then 0x0x410b0eec should be the typename pointer. Assuming it is a _vptr. This only applys if the typeinfo is present in the program and not an external library.