Ghidra: the bytes column is not the mnemonic

A Listing row carries two different fields

Turn on the bytes field in the Listing if it is hidden. That column is the sequence the database stored for the row under the cursor. The mnemonic to the right is the name the disassembler assigned when it decoded those bytes. They sit on one row so you can check them together. They are not the same string.

An operand is a third field. CALL and the name it calls are both part of the decode. Neither one replaces the hex in the bytes column.

The mnemonic is only a decode

The disassembler chose a mnemonic because those bytes matched an instruction pattern for the language you accepted at import. A different language would name them differently, or not at all. Quoting CALL is fair when you are quoting the decode. Quoting it as the bytes is a swap.

If the row is undefined, there is no mnemonic yet. Leave the decode blank in the note. Do not copy a mnemonic from the next row upward.

How a row goes into the notebook

Write the address, the bytes column, and the mnemonic on separate labels. If you also mention the operand, label that too. A sentence that says the bytes are the mnemonic has mixed the fields and should be rewritten before it leaves the lab.

Lab: one call row, written twice

In the lab program, find a direct call whose Listing row shows a bytes column and a CALL mnemonic. Copy both fields, plus the address. A useful draft to correct is one that says the bytes are CALL.

Replace that draft with the two labels. The hex stays the stored bytes. CALL stays the decode. The operand, if you include it, is the target the decode named, not a third spelling of the hex.

One lab row, written as two fields

address: 00101310
bytes: e8 3a 00 00 00
mnemonic: CALL
operand: FUN_0010134f
write: bytes and mnemonic
not: the bytes are CALL