On an eight-bit part with fixed-length instructions, disassembly is a loop: read a word, decode it, advance, repeat. The result is a listing, and the listing is right up to the point where data begins.

On a thirty-two-bit core with variable-length instructions none of that holds. The decoder cannot know where the next instruction starts without knowing where the current one ends, and it cannot know where the current one ends without decoding the first byte correctly. A single misalignment propagates for the rest of the file. What comes out is not a listing with some errors; it is a listing that gradually stops corresponding to anything.

R5F562T7BDFF#V1 is an RX62T group device — hundred-megahertz core with an FPU, two twelve-bit converter units, the motor-control timer and inverter protection logic. Recovering code from it is a process of finding boundaries and then decoding between them, in that order.

Length comes from the top of the byte

The third and fourth rows are the dangerous ones, because a misaligned stream still tends to produce legal instructions. That means an automated tool does not report failure — it reports success with a listing that is quietly wrong. The only defence is to establish boundaries independently of the sweep.

Literal pools inside the instruction stream

Compilers for this architecture place constants inline. A load of a large immediate is often compiled as a PC-relative load from a pool of literals that sits a few instructions away, sometimes in the middle of a function, sometimes between two functions where the alignment worked out.

Two consequences follow for a recovered image. First, the pool bytes are not instructions and must not be decoded as such — a pool of two or three addresses decodes into a handful of legal-looking instructions that reference registers the function never touches. Second, the pool is a reliable boundary marker: a run of words that are all plausible addresses, surrounded by PC-relative loads targeting them, is almost certainly a literal pool, and the function ends somewhere after it.

Recognising pools is the single highest-value skill in this work, because it is the check that stops a listing from claiming that a data table is a subroutine.

Finding function starts without symbols

There are no names in a recovered image. There are, however, four signals that converge.

Call targets are the strongest. Every call to a fixed address proposes a function start, and the set of all call targets in an image is a good first approximation of the function list.

Prologue patterns are the second. Compilers that build a stack frame emit a recognisable sequence at entry, and on this architecture that sequence is short and consistent enough to search for.

Alignment is the third. Compilers align function entries, which means a candidate start at an odd address is not a start.

And the vector table at the top of the map is the fourth, and the most authoritative: it names the entry points the hardware uses, and those entries are function starts by definition. A listing that disagrees with the vector table is a listing that has lost the plot.

Where a listing lies

Three specific lies appear in almost every recovered listing, and each has a tell.

A switch statement compiled as a jump table produces a data block of code addresses inside the function. Decoded as instructions, it produces a run of branches to nearby addresses that no source would contain. The tell is a dense cluster of jumps whose targets are all inside the same region and none of which is called from anywhere.

A tail call — a jump to another function’s entry instead of a call and return — breaks the assumption that a function ends with a return. A reviewer counting returns to find the end of a function will run past the boundary.

And an island of data inside a code region, placed there by the linker to fill an alignment gap or to hold a string, decodes as instructions and is usually harmless. The tell is that nothing branches into it and it branches nowhere.

Five checks on a listing you did not produce

A customer reviewing a delivered listing, or an engineer reviewing a colleague’s, needs cheap checks rather than deep ones.

Does the reset vector decode to a plausible address, and does the code at that address look like an initialisation sequence rather than like the middle of something.

Does every call target land on something that looks like a function entry, rather than in the middle of a table or a pool.

Is the number of identified functions plausible for the image size — a dozen for a hundred kilobytes suggests the analysis stopped early, several thousand suggests it is decoding pools as code.

Do the peripheral initialisation sequences appear before the main loop, and are they consistent with the peripherals the package can actually bond out.

And does the listing account for the whole image, or does it quietly stop at the first region the tool could not classify. That last one is the most common defect in delivered work and the easiest to miss, because the file simply gets shorter.

For the byte-order check that must pass before any of this is meaningful, R5F562T7BDFF code breaking covers that comparison. For the file format that carries the image, R5F562T7EDFF heximal deals with records. And for a source-level deliverable rather than a listing, R5F562T6ADFK software sets out what that engagement actually contains.

FAQ

Can a disassembler handle variable-length instructions automatically? It can decode them once aligned, and it cannot recover alignment by itself with certainty. Alignment comes from entry points, not from sweeping.

Why are literal pools inside functions? Because a PC-relative load is cheaper in code size than a long immediate for values that repeat. The compiler puts the value where it can reach it.

Is a listing the same as source? No. A listing has addresses and instructions; source has names, types and structure. Converting one to the other is manual work, and the amount of it is what separates a cheap quotation from an honest one.

The short version

Boundaries first, decoding second. Use call targets, prologues, alignment and the vector table to propose function starts, then decode between them and mark the literal pools so they are not mistaken for code. Check the result against five cheap properties, and never deliver a listing that stops early without saying so.

Comments are closed.