improvements about ghidra

[DarrylC03]

@mumbel should I report issues here with the tricore processor? I am using the December public release but will try and get the build to work for the latest release on W10 as well. No priority as I can get most of what I need by using a combo of IDA and Ghidra. There are still missing code between compiler generated functions:

which should be decoded as:

As well as these type of "off by 1" failure to decode correctly:


Which Ghidra does quite a bit with the last jump statements in a jump table.

You can see from this image that IDA also does analysis of the stack variables as well. I like the Ghidra choice here but others may prefer what IDA does especially in this case where the function cannot be decompiled to C (unknown error)

[mumbel]

Hey, @DarrylC03 , I don't mind looking at bug reports here, but you might eventually get attention from the Ghidra devs if you post an issue there. A lot of stuff, unless an actual instruction decoding bug (for the most part this is all I think I could promise to reasonably help/fix), I just don't know enough fix in most cases.

The last screenshot does seem kind of surprising, I do have a10 listed as the stack pointer, so not sure what to do about that, seems auto analysis would pick that up. The first two are a change in code flow that I'm not sure how Ghidra decides to keep disassembling by address or continue with code flow, I'd think it would attempt to disassemble in those examples too.

One area I'd really like to get some time to spend on is the decompiler, but just haven't yet. things like bad switches and the resulting disconnected code flow and low-level messages like yours are super frustrating, I get those on other processors too. I really don't know if that's some issue with the SLEIGH I implemented as-is for each instruction or just instructions that regardless of the implementation the decompiler would choke on due to complexity.

[DarrylC03]

Thanks Mumbel, I will put a link to these comments on the tricore enhancements thread and start adding the requests there. Awesome work BTW. Regards, Darryl.

…

On Mon, 17 Feb 2020 at 14:00, mumbel ***@***.***> wrote: Hey, @DarrylC03 <https://github.com/DarrylC03> , I don't mind looking at bug reports here, but you might eventually get attention from the Ghidra devs if you post an issue there. A lot of stuff, unless an actual instruction decoding bug (for the most part this is all I think I could promise to reasonably help/fix), I just don't know enough fix in most cases. The last screenshot does seem kind of surprising, I do have a10 listed as the stack pointer, so not sure what to do about that, seems auto analysis would pick that up. The first two are a change in code flow that I'm not sure how Ghidra decides to keep disassembling by address or continue with code flow, I'd think it would attempt to disassemble in those examples too. One area I'd really like to get some time to spend on is the decompiler, but just haven't yet. things like bad switches and the resulting disconnected code flow and low-level messages like yours are super frustrating, I get those on other processors too. I really don't know if that's some issue with the SLEIGH I implemented as-is for each instruction or just instructions that regardless of the implementation the decompiler would choke on due to complexity. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#21?email_source=notifications&email_token=AGEX7WGDO57R2FFKVT2FEDTRDH4WHA5CNFSM4KCJMIUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL45FFY#issuecomment-586797719>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGEX7WHFCS5YKH5CMXBHDOLRDH4WHANCNFSM4KCJMIUA> .