H8/300H normal mode implementation errors

[Thodoris1999]

Hi, I am currently trying to implement H8/300H in ghidra and I am getting a couple of hard-to-debug issues

The issue

I am often getting a message in the decompiler panel saying "Offset must be between 0xffffffffffff8000 and 0x7fff, got 0xfffffffc instead!" (sceenshot)

The behavior

This architecture has a jsr instruction, which similar to x86's call automatically pushes the next instruction address and jumps to the target. rts is the matching return instruction. Similar to the instructions here https://spinsel.dev/assets/2020-06-17-ghidra-brainfuck-processor-1/ghidra_docs/language_spec/html/sleigh_constructors.html, I am manually moving the stack pointer and saving the return address on function calls, and popping it on return.

My definition for the call is

:jsr absaddr24.w is op8=0x5E; absaddr24.w {
        pushpc();
        call absaddr24.w;
}

where pushpc is:

macro pushpc() {
   er7 = er7 - 4;
  *:3 er7:2 = &:3 inst_next;
}

These are my definitions (make, make install): https://github.com/Thodoris1999/H8-38602R
Tested on function at offset 0x36f2 in this .gzf: https://drive.google.com/file/d/1KYd4kRt_jljxpoJsCydu9pSXfG0IDdZH/view?usp=drive_link

Additionally, what is the workflow to debug these errors? Is there a tool that does inspection and nice visualization of pcodes?

[GhidorahRex]

As far as debugging the errors, there's a listing field for pcode that can be enabled. It shows the pcode for each instruction. That may be helpful for you. Hopefully that can indicate what could be causing that offset

[Thodoris1999]

That would be useful yeah. I have some trouble enabling it though, it appears greyed out, if this is the one you were referring to

[GhidorahRex]

You should be able to right-click on it and select "Enable field"

[Thodoris1999]

ohhh that's very cool thanks : )

I forgot to mention that the problem disappears when I comment out my pushpc macro (hence the reason I specifically mentioned it), but it produces issues on the stack (local variables appear as stack000000000x)

In the meantime I got the pcode using decomp_dbg https://pastebin.com/a5y4r3rm. Nothing immediately suspicious, but I've got a ton of info to debug ( yay :( )

[Thodoris1999]

Update: I am still haunted by these issues, but I've got some new info.

I've narrowed down the cause of that message to er7 (stack pointer) being decreased by 4 every time a function is called in pcode. This is indeed what the architecture does and I see a similar pcode implementation in x86.
Notice that the decrease is 4 and the error mentions fffc. For example if I change it to 6 the error changes to fffa.

As far as I know, popcount and stackshift=4 should take care of telling ghidra that a return address is automatically pushed and popped across function calls. So idk why that "stack offset" gets below zero

If I remove the pcode that decreases er7, I can finally see a decompilation but for some odd reason pc return address saves start appearing, even though it should be dead code. This happens whether er7 is marked as unaffected or not.

Any ideas?

[GhidorahRex]

I've never seen that error. A couple thoughts:
You can try adding growth="negative" to your stackpointer definition like so:<stackpointer register="er7" space="mem" growth="negative"/>
Second, I don't know anything about this architecture, but it seems strange to me that the stack pointer is 32-bits but you only use 16-bits to access the stack. I'm not sure how that works.

[Thodoris1999]

Yea this architecture is weird, I haven't seen anything like it. It has a "normal" and "advanced" mode which uses 16 and 32 bit addressing respectively and the stack pointer is defined to be er4 in both cases. The top two bytes are ignored anyways so I didn't think much of it BUT:
Changing the stack pointer in cspec to r7 (lower two bytes of er7) magically fixes everything! Thanks for the suggestion!