8051 DPTR tracking across functions

[phlash]

Hi folks - I'm struggling to find a solution to what must be a common situation in 8051 disassembly - tracking the value of DPTR across functions that alter it's value, such that subsequent symbol lookups are valid - here's my example:

as can be seen: DPTR starts at a known value (0xf9bc), it is then incremented twice (to 0xf9be) and dereferenced to store values in memory. I have labelled these addresses and the labels are correctly displayed. A call is then made to part_save_ptr@dptr which increments DPTR twice more as a side-effect (to 0xf9c0), but this is not propagated back to the caller, which then uses the wrong value for DPTR (0xf9be still) to lookup additional symbols or display an address in memory for the remainder of the calling function. IMO this is worse than ignoring DPTR values, since it is actively confusing!

How should I configure Ghidra to correctly track the DPTR value? Or how can I prevent it from making the wrong assumptions after a function call that modifies DPTR?

I have tried a couple of things (from the manual/tutorials) that do not work:

• marking the called function in line - this partly works for the decompiler but has no effect on disassembly?
• declaring DPTR as in/out storage for a parameter to the function - no effect on disassembly.
• using set register value after the call to force DPTR to 0xf9c0 - no effect on disassembly. This seems broken?

Note that this structure occurs many hundreds of times through this Keil C51 compiled target code - I would be averse to having to manually fix up every call site! 😄

Suggestions gratefully received, Phil.