Decompiler: parameters based on indirect addressing - CODE vs. DATA segment

[mh-]

This relates to ghidra 9.0.4 and the PIC processors, I'm specifically working with a PIC16F153xx.

An assembly sequence like this

CODE:0008 20 30           MOVLW      #0x20
CODE:000a 84 00           MOVWF      FSR0L
CODE:000b 00 30           MOVLW      #0x0
CODE:000c 85 00           MOVWF      FSR0H
CODE:000d 4b 30           MOVLW      #0x4b
CODE:000e 82 31           MOVLP      #0x2
CODE:000f 97 22           CALL       clearBuffer   (byte clearBuffer(byte * buffer, ...)

is decompiled to

  clearBuffer((byte *)((short)configureOscillator + 1),0x4b);

Inside the function clearBuffer(byte *buffer,byte len)

                             **************************************************************
                             *                          FUNCTION                          *
                             **************************************************************
                             byte __stdcall clearBuffer(byte * buffer, byte len)
                               assume PCLATH = 0x2
             byte              W:1            <RETURN>
             byte *            FSR0:2         buffer
             byte              W:1            len
                             clearBuffer                                     XREF[1]:     CODE:000f(c)  
       CODE:0297 64 00           CLRWDT
                             LAB_CODE_0298                                   XREF[1]:     CODE:029b(j)  
       CODE:0298 80 01           CLRF       INDF0

the indirectly addressed parameter FSR0 is accessed e.g. via INDF0, like CLRF INDF0.

Now here is my question:
The decompiled function call

  clearBuffer((byte *)((short)configureOscillator + 1),0x4b);

shows an (unrelated) label "configureOscillator + 1" from the CODE segment.

However, PIC FSR0/FSR1/INDF0/INDF1/... instructions access the DATA segment.
Both segments use overlapping addresses (starting at 0x0000).
How can I make ghidra show labels from the DATA segment for this decompiler use case?

[mh-]

Ok, I found a possible solution in GhidraDocs/languages/html/sleigh_definitions.html#idm140310875499872 (Section "4.3 Space Definitions):

At least one space needs to be labeled with the default attribute. This should be the space that the processor accesses with its main address bus. In terms of the rest of the specification file, this sets the default space referred to by the ‘*’ operator

Currently, pic16.sinc has

# Instruction Memory (ROM-based)
define space CODE type=ram_space wordsize=2 size=2 default;

When I remove the default attribute there, and instead add it to

# General Purpose Register Memory consists of 4-banks of 255-bytes for PIC16,
(...)
define space DATA type=ram_space size=2 default;

then the decompiler works as desired for the use case above.

It does have the undesired side-effect that the disassembler now thinks that the program code belongs into the DATA memory, though.

(BTW, the Sleigh documentation also mentions a rom_space type that would be more appropriate for the PIC CODE space, however, it doesn't seem to be implemented in Sleigh currently?)

[emteere]

You can try using the following in the .pspec file, but I don't think this will quite help you, although it might make some other things work better.

....
<processor_spec>

  <programcounter register="PC"/> 
  <data_space space="DATA"/>
 ....

By your program in the data space, do you mean when you load it?
If you always specify the address space in your pcode, then it will refer to the right space, except for values that are passed to functions. Take a look at the AVR8, as it suffers from this same issue.

rel7addr: rel is op3to9signed [ rel = (op3to9signed + inst_next);] {
export *[code]:2 rel;
}

[mh-]

except for values that are passed to functions

This was the problem I initially encountered - values that are passed to functions.
I want Ghidra to know hat these values are from the DATA space (and therefore show the correct labels).
Is there no way to achieve that?

[emteere]

You can override the branching flow, but the decompiler currently only has a default space.
We have had this on the books for quite a while, and have a plan to address it in the next release or so along with a few other things related to this type of hint issue. The idea is to add an address space tag to data types in certain uses such as parameters and structures. Very similar to attribute() or other tags that GCC uses on a data type.

I think the best thing is to set the default data space, and make sure any code references are caveated with correct [CODE] [DATA] access when the value is used as an address. I'm not sure what you mean by now your code references are going to the data space.Iis that when passed to parameters, or within the disassembly flow?

[mh-]

When I set the default DATA space, a .hex file is imported into this DATA space, even if I set the base address to CODE: in options:

[mh-]

Regarding

I think the best thing is to set the default data space, and make sure any code references are caveated with correct [CODE] [DATA] access when the value is used as an address.

I can only either use *[const]:2 or *[CODE]:2, but not both, correct?
Unfortunately I need the *[const]:2 caveat to avoid false switch/case detections.