V850 discussion

[brainstorm]

Running Ghidra 10.3 from HEAD. The example binary I'm testing this with is this V850 blob

After "Start emulation here", I step once and get the following:

Cannot invoke "ghidra.app.plugin.core.colorizer.ColorizingService.clearBackgroundColor(ghidra.program.model.address.Address, ghidra.program.model.address.Address)" because "service" is null
java.lang.NullPointerException: Cannot invoke "ghidra.app.plugin.core.colorizer.ColorizingService.clearBackgroundColor(ghidra.program.model.address.Address, ghidra.program.model.address.Address)" because "service" is null
	at ghidraemu.GhidraEmuPopup.unsetColor(GhidraEmuPopup.java:167)
	at ghidraemu.GhidraEmuProvider$5.keyReleased(GhidraEmuProvider.java:390)
	at java.desktop/java.awt.Component.processKeyEvent(Component.java:6577)
	at java.desktop/javax.swing.JComponent.processKeyEvent(JComponent.java:2905)
	at java.desktop/java.awt.Component.processEvent(Component.java:6393)
	at java.desktop/java.awt.Container.processEvent(Container.java:2266)
	at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:4991)
	at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2324)
	at java.desktop/java.awt.Component.dispatchEvent(Component.java:4823)
	at java.desktop/java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1952)
	at java.desktop/java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(DefaultKeyboardFocusManager.java:883)
	at java.desktop/java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(DefaultKeyboardFocusManager.java:1146)
	at java.desktop/java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:1020)
	at java.desktop/java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:848)
	at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:4872)
	at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2324)
	at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2780)
	at java.desktop/java.awt.Component.dispatchEvent(Component.java:4823)
	at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:775)
	at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:720)
	at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:714)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
	at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
	at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:97)
	at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:747)
	at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:745)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
	at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
	at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:744)
	at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)

---------------------------------------------------
Build Date: 2022-Dec-12 1243 AEDT
Ghidra Version: 10.3
Java Home: /opt/homebrew/Cellar/openjdk/18.0.1/libexec/openjdk.jdk/Contents/Home
JVM Version: Homebrew 18.0.1
OS: Mac OS X 12.6 aarch64

[Nalen98]

Hello!

I was unable to reproduce this on Ghidra 10.3 HEAD.
My steps:

• got this extension for v850: https://github.com/esaulenka/ghidra_v850
• opened in Ghidra and tried to start emulation process (got no bugs):

What am I missing?
Based on the error you provided, the ColorizingService has not been initialized.
If possible, please provide more details on what you did so that I can reproduce and fix this error deeper than simple exception handling.

[brainstorm]

I did not use that 3rd party V850 extension, but the included V850 support that Ghidra already has. That being said, I closed & reopened Ghidra today and couldn't reproduce either 🤷🏻‍♂️ So I'm closing this issue, thanks for the fast response!

I'm getting the error on the second emulation step though:

The first "Step" on offset 0x00001298 works fine and updates the PC accordingly. I'll need to investigate those options and settings, thanks again for your support!

[Nalen98]

Thanks for your activity!

I still believe that this is not your fault and the error is worth handling. I'll let you know when I've finished my investigation.

[Nalen98]

c39ba4a

This commit successfully fixes this problem.
Every call to step#EmulatorHelper or run#EmulatorHelper discarded the previously prepared value of the stackPointer into its own (0xFFFFFFFF). Now the plugin also uses this value (only for V850). This change allowed to avoid such errors.

Before you try, don't forget to specify the link register in the Registers View:
https://github.com/Nalen98/GhidraEmu#register-view

Be sure to contact if you notice any other strangeness or errors.

[brainstorm]

Updated to HEAD today and I have a bit more information, namely the error message from the console:

Without squinting at the screenshot, here's what it says in plaintext:

GhidraEmu> Unable to read bytes at ram:fffff420

Is it possible to make GhidraEmu assume that bytes at that location are uninitialised? Here's the default memory map when importing the binary, if it helps:

[Nalen98]

Hi!

Take a look at my MemoryMap with the same binary, I guess:

As I mentioned before in previous #6 (comment), in V850 I discovered a strange behavior that, when starting emulation, the stackpointer's value is assigned to 0xFFFFFFFF without the knowledge of the plugin (it's a question for the developer of this processor module in Ghidra). Now I made it in c39ba4a so that for V850 processor the stack space will be created according to default 0xFFFFFFFF address.

I see in your MemoryMap that you probably didn't reload this Ghidra project (cmciocbl.bin). Try setting the stack ranges manually (0xFFFFE000 - 0xFFFFFFFF), or if circumstances permit, delete this project and create a new one with the same binary. The stack will be automatically allocated to the required addresses in this case.

The plugin warning:

GhidraEmu> Unable to read bytes at ram:fffff420

related to the stack space and I hope my hint will help you deal with it.

[brainstorm]

Thanks a ton @Nalen98 for the fixes and detailed explanation! I tried both setting the stack/ram manually as suggested and recreating the project. The first didn't work (same issue as before with the new maps), but the recreation worked and I managed to get a bit further on the static emulation, this plugin shows a big promise, well done!

Unfortunately, after a few steps, the emulation stopped on a seemingly trivial instruction:

Plus as you can see, most of the stack remains uninitialized, which it shouldn't after offset 0x12A0, where the sp is set?

[Nalen98]

sp register can be found in the RegistersView (just scroll down a little bit in this window). The start default sp value for v850 is 0xFFFFFFFF.

After a few of improvements in 8075d5b I've tried to reproduce this case and here's what I've got:
Start address = 0x0
-> press "Run"

Emulator stops at address 0x29f8 because it doesn't know about how to deal with non-existing memory space at 0x03ffef7c. This is expected behavior since the emulator is not capable of reading from memory that does not exist.