Many years ago I had to convert an assembly language floating point package to pure code. I tried to shoehorn fixes in, but in the end found that only a total rewrite cured the problem. No matter how carefully you design a new project, it is far too easy to inadvertently slip in the occasional impure data reference. In an upgrade to an old project the problem is more severe, as you may not be totally comfortable with the code's structure or the original programmer's intents. I doubt if there is a complete test exist for reentrancy.
Some partial tests are easy and well worth the effort.
Any decent emulator lets you catch writes to program space. When using a ROM monitor, simulator, or the like, regularly run checksums on the code. In assembly language routines, any direct reference to a RAM address is cause to examine reentrancy issues. Still, it might be a flag that the code is impure. A sure-fire solution is to store local variables in the current stack frame.