Warnings and errors analyzing Intel's NINDY 3.01 binary about ghidra_i960 HOT 8 CLOSED

Sounds interesting, good luck

from ghidra_i960.

Thanks for the sample. I do remember coming across that as well. I haven't a a clue what it is or what it means, guess I might need to run a debug build in eclipse.

from ghidra_i960.

@cglmrfreeman Maybe fixed. 2d29779

Not sure if this is a complete fix, but any COBR instruction format that used a immediate value had issues as it could not determine the number of bits of the value.

from ghidra_i960.

@cglmrfreeman came across your stack exchange post. Looks like its hitting this same error when it decodes the scale (at least when i debug the instruction you have posted with DebugSleighInstructionParse.java). I'll try to look into this a little more

maybe cb4513f will help if youre still hitting Bit length must be >= 1 and <= 64

from ghidra_i960.

Thanks much! Will check this out when I get a chance. I'm in the process of assembling an IDA disassembly and am discovering IDA omits quite a bit that maybe Ghidra could label properly. I'm sure once I am done with my disassembly producing an 1:1 binary with a newlib assembled disassembly, we could learn a lot from comparing Ghidra output to the disassembly.

from ghidra_i960.

Looks like the error I got is fixed when loading NINDY! I still get the warning, but I guess that's okay. Gonna close the issue now, I'll let you know if something new pops up!

from ghidra_i960.

@cglmrfreeman I think the warning was from 78225cf, but I added a lot in 1a0e239 since trying to repro that, so it might have been related to something there. But can't get the warning anymore, auto-analysis seems to work with defaults. Didn't find all the code, but did alot.

from ghidra_i960.

@cglmrfreeman sorry to ping again. I added more commits today that should be helpful, at least for your particular binary from #1. it should remove all cases of unimplemented instruction. I made pcodeops for scanbit and send, its not doing anything with the instruction, but you'd see __scanbit or __send in decompiler at least. Absolute addressing is now unsigned (etc for accessing reserved high 12MB, you'll see 0xff000010 instead of -0xfffff70 or whatever it'd be), and bal and balx should have better flow control during disassembly/auto-analysis.

from ghidra_i960.