Specifications
Page 11
❏ pushing an address onto the stack and then, later, performing a return
from subroutine instruction (i.e. as a method of performing a jump);
❏ performing an indexed branch instruction (e.g. using addresses taken
from a vector table);
❏ use of undocumented instruction opcodes – since threads are
abandoned when an invalid opcode is detected;
❏ self-modifying code.
Indexed branch instructions are highlighted in the output listing by automatically
generated comments. These are an indication that you need to manually identify
what the contents of the index register will be prior to the branch (often obvious –
look for a preceding load index register instruction.) Then, you can add a code or
a vectab entry to the symbol file and repeat the disassembly.
In rare cases, code threading may incorrectly identify data as code:
❏ A call to a subroutine that never returns (e.g. the subroutine discards the
return address); the other side of the call containing data rather than
code.
❏ A conditional branch that is always, or never, executed (and the other
side of the branch contains data rather than code).
Normally this latter scenario is pretty unlikely and requires a particularly perverse
programmer of the original code. However, it is a technique that may be
encountered on those processors which had a "better" (i.e. fewer cycles and/or
fewer bytes) conditional jump than unconditional jump. So, in general, code
threading will identify guaranteed known areas of code that may be a subset of the
overall actual code. Most of the above problem areas can be dealt with by manual
inspection of the disassembly listing and subsequent additions to the symbol file.
A thread of execution will be abandoned for one of two reasons. If a branch or
subroutine call is made outside the address range corresponding to the source
image then that thread is not followed. Also, if an invalid instruction is detected
then the thread terminates immediately. This will produce a command line error
message identifying the address where the problem occurred. Normally this
represents an error condition that can be corrected by the person operating the
disassembler:
❏ the processor type is incorrectly specified;
❏ the source binary image is not real code;
❏ an incorrect code entry point has been supplied;
❏ so called "undocumented" instructions have been used.
In rare cases, the original programmer may have done something that causes the
code threader to incorrectly identify data as code. These cases may also result in
invalid instruction messages.