This is the first patch intended to make a more precise pracc check
when running in legacy mode (code executed by mips32_pracc_exec()).
It only makes some cleanups, mostly due to unnecessary code.
With the last cache optimizations for processor access (pa for short)
all the pracc functions generate the code following some rules that
make pa more easily to check:
	There are no load instructions from dmseg. All the read pas are
	instruction fetches. PARAM_IN related stuff is not needed.
	Registers are restored either from COP0 DeSave or from ejtag
	info fields. PRACC_STACK related stuff is not needed any more.
	The code starts execution at PRACC_TEXT and there are no branch or jump
	instruction in the code, apart from the last jump to PRACC_TEXT.
	The fetch address is ever known.
	For every store instruction to dmseg the function code sets
	the address of the write/store pa.
	The address of every store pa is known.
Current code ends execution when reading a second pass through PRACC_TEXT.
This approach has same inconveniences:
	If the code starts in the delay slot of a jump it makes a jump
	to PRACC_TEXT after executing the first instruction. A second pass
	through PRACC_TEXt is read and the function exits without any warning.
	This seems to occur sometimes when a 24kc core is halted in the delay
	slot of a branch.
	If a debug mode exception is triggered during the execution of a
	function the core restarts execution at PRACC_TEXT. Again the function
	exits without any warning.
	If for whatever reason the core starts fetching  at an unexpected
	address the code now sends a jump instruction to PRACC_TEXT, but due
	to the delay slot the core continues fetching at whatever address + 4
	and a second jump instruction will be send for execution. The result
	of a jump instruction in the delay slot of another jump is
	UNPREDICTABLE. It may work as expected (ar7241), or let the core in
	the delay slot of a jump to PRACC_TEXT for example. This means the
	function called next may also fail (pic32mx).

Change-Id: I9516a5146ee9c8c694d741331edc7daec9bde4e3
Signed-off-by: Salvador Arroyo <sarroyofdez@yahoo.es>
Reviewed-on: http://openocd.zylin.com/1825


Tested-by: jenkins
Reviewed-by: Freddie Chopin <freddie.chopin@gmail.com>