ABratovic
commented
4 years ago I note the change from [register] to [ram] is same as my workaround. If this is is the desired resolution then all the text at beginning of tricore.sinc that populates the [register] space should also be deleted. I would consider #1640 (plus removing the redundant register defines currently in tricore.sinc) is the correct solution based on this note in SLEIGH doco _
A space of type register_space is intended to model the processor’s general-purpose registers. In terms of accessing and manipulating data within the space, SLEIGH and p-code make no distinction between the type ram_space or the type register_space. But there are still some distinguishing properties of a space labeled with register_space.
It is read/write. It is not part of the standard memory map of the processor. In terms of GHIDRA, there will not be separate windows for the space and references into the space will not be stored. Named symbols within the space will have Register objects associated with them in GHIDRA. It is not addressable. Data-flow analysis will assume that data within the space cannot be manipulated indirectly via pointer, so there is no pointer aliasing. Make sure this is true!
_
Describe the bug mfcr/mtcr instructions show in disassembly but not in the decompilation.
To Reproduce
Expected behavior read/write from Special Function Register should be shown in decompile window.
Screenshots
Attachments test_tc1767.zip
Environment (please complete the following information):
Additional context if I change mtcr sleigh from [register]:4 const1227Z = Rd0811; to [ram]:4 const1227Z = Rd0811; then I get output in decompile window, but alas without the write volatile prefix or register name.