MZ EXE loader segments get out of sync with Program Tree fragments

[agatti]

Describe the bug

Program Tree fragments start/end addresses do not reflect memory block adjustments applied by the MZ DOS EXE loader after blocks creation.

To Reproduce
Steps to reproduce the behavior:

1. Import the attached EXE file with default settings.
2. Open the file, skip the analysis (the issue still occurs even after analysis).
3. Bring into view the CODE_2 block from the "Program Trees" pane.
4. Scroll down to the end, the block should end at 11C3:29DD, but the listing is cut off at 11C3:29CF.

Expected behavior
Program Tree fragments start/end addresses should match the ones from the Memory Map pane and listing should allow viewing the whole block.

Screenshots

Attachments
mz_dos_blocks.zip

Environment (please complete the following information):

• OS: Linux Arch x86_64
• Java Version: 17.0.10
• Ghidra Version: 11.1
• Ghidra Origin: locally built at 317a881

Additional context
You can also try to bring CODE_3 into view, the start offset does not consider the block adjustment - see screenshot.

[haarlaj]

I'm working on another DOS executable (CATS.EXE in bug report #5970) and it has the same behavior as this. It seems to be related to the CODE sections where the source is defined as empty in the memory map, e.g. CODE_3 above.

This bug seems to present itself in places where CODE section where source is "mz" is followed by CODE section where source is empty.

Should there be any CODE sections where source is empty in the first place?

[agatti]

@haarlaj I missed the detail about the lack of blocks' source! From a quick look at the code it happens to blocks that are split and joined together as part of the adjustment process:

ghidra/Ghidra/Features/Base/src/main/java/ghidra/app/util/opinion/MzLoader.java

Lines 293 to 302 in b82294b

	if (val == FAR_RETURN_OPCODE) {
	// split here and join to previous
	Address splitAddr = offAddr.add(1);
	String oldName = block.getName();
	memory.split(block, splitAddr);
	memory.join(blocks[i - 1], blocks[i]);
	blocks = memory.getBlocks();
	blocks[i].setName(oldName);
	break;
	}

So I guess it's those extra blocks whose address bounds are not in sync with the program tree list.

[ryanmkurtz]

This is correct. The initial Program Tree is automatically formed when the memory blocks are created. Any kind of memory block manipulation that happens later will not be automatically reflected in the Program Tree...it requires manual fix up (which we are not currently doing).

[ryanmkurtz]

I am going to (at some point) work on fixing this Program Tree syncing issue. In the meantime, if you just create a new Program Tree, it will reflect the current memory map.

[agatti]

It worked, thank you!