mips3 drc : missing label for branch destination, destination in unmapped page

[Happy-yappH]

Details, drc log

conkeru_drc_issue.txt

or also at

https://gist.github.com/Happy-yappH/e71f8c4b01d177436a8e8045c32a5546#file-conkeru_drc_issue-txt

[MooglyGuy]

This is a bit complicated, but here's my best reckoning of what it's doing:

Based on the two "exh tlb_mismatch,$0" in a row in the handler for the opcode at $15003050, I'm going to hazard a guess that it's being emitted by mips3_device::generate_sequence_instruction.

Furthermore, note the location of the "; -------------------------" comment in the DRC log, and where it's added to the log: At the start of an instruction sequence, inside the loop in mips3_device::code_compile_block.

The interesting thing to note is that if the lack of that comment further down in the DRC log is to be believed, the opcodes at $15003000 and $15003050 are being treated as being in the same instruction sequence that starts at $15002FF4.

Both $15003000 and $15003050 are being acknowledged as a branch target by the underlying DRC system, but see how code_compile_block calls generate_sequence_instruction in a tight loop? If any of the instructions in the sequence are flagged by the system as OPFLAG_IS_BRANCH_TARGET, it won't actually generate a label for them. It seems that it will only emit a label for a branch target if the branch target is the first instruction in a sequence.

It's just a wild guess, but consider moving the "label this instruction, if it may be jumped to locally" logic into generate_sequence_instruction, and using desc-flags and desc->pc instead of seqhead->flags and seqhead->pc.

[Happy-yappH]

code_compile_block receives three sequences and the seqhead for each are respectively 15002FE4, 15002FF4 and 15003050. The 15003050 should still be labeled by the OPFLAG_IS_BRANCH_TARGET test.

[Happy-yappH]

Also if the branch isn't taken at 15002FFC there should be a 15003004 instruction at label $1 for the branch. The lack of 15003004 in the description list is a failure of the drcfe to recognize this situation for a conditional branch straddling a page boundary.

[MooglyGuy]

Well, I'm out of ideas, then. If it's a fault in drcfe, then there's not much I can do as I'm as familiar with it as you at this point.

[aaronsgiles]

(Sorry, sent a reply to the mailing list but it seems to want to ignore me.)

I think the problem is that there is missing logic for a intra-block branch to a virtual no-op. VNOPs are placeholders for when the instruction stream hits missing code due to a page fault. If it was just the fall through case it would probably be ok, but since you have a branch to something that's not mapped, it's confused.

There are several ways to address the issue.

Simplest would probably be when generating an intra-block branch in mips3fe, check the mapping of the target PC, and if it's not mapped, convert it to an inter-block branch (i.e., make it go through the dispatcher).

Another more general option would be to add logic in drcfe.c describe_one() after calling describe() to do the same check for the target PC. The problem is that the generic drcfe doesn't know about translation, but we can check for a virtual no-op in the target.

After looking at it, this might be a quick way to resolve it. I haven't tested it, but you can try making this change to drcfe.c. In describe_code(), change this line:

			// stop if we hit a page fault
			if (curdesc->flags & OPFLAG_COMPILER_PAGE_FAULT)
				break;

to this:

			// stop if we hit a page fault
			if (curdesc->flags & OPFLAG_COMPILER_PAGE_FAULT)
			{
				// if another block branched here (implied by being the first instruction), convert that branch to an inter-block branch
				if (curpc == curstack->targetpc && curstack->srcpc != 0)
					m_desc_array[curstack->srcpc - minpc]->flags &= ~OPFLAG_INTRABLOCK_BRANCH;
				break;
			}

Let me know how it goes.

Aaron

[Happy-yappH]

Changing mips3_device::generate_delay_slot_and_branch to check if the targetpc is mapped before generating a JMP and instead generating a HASHJMP, fixes the issue with no label found, as it no longer will generate something that is looking for the label.

/* update the cycles and jump through the hash table to the target */
if (desc->targetpc != BRANCH_TARGET_DYNAMIC)
{
	generate_update_cycles(block, &compiler_temp, desc->targetpc, true); // <subtract cycles>
	offs_t temp_target = desc->targetpc;
	if ((desc->flags & OPFLAG_INTRABLOCK_BRANCH) && (memory_translate(AS_PROGRAM, TRANSLATE_FETCH, temp_target)))
		UML_JMP(block, desc->targetpc | 0x80000000);                            // jmp     desc->targetpc | 0x80000000
	else
		UML_HASHJMP(block, m_core->mode, desc->targetpc, *m_nocode);
																				// hashjmp <mode>,desc->targetpc,nocode

Now, the issue is execution reaches the branch as 15002FFC and checks for a tlb_mismatch at 15003000, but the tlb_mismatch recovers the pc as 15002FFD and checks that against the TLB, when it needs to recover the actual address 15003000 to check against the TLB. With 15002FFD it does not see the address (15003000) as unmapped and fails to generate a TLB exception.

[aaronsgiles]

Did you try my more general and simpler solution and find it lacking? This logic really should be part of the general drc engine, not hacked into each core. Aaron

…

________________________________ From: Happy-yappH <notifications@github.com> Sent: Apr 1, 2017 12:03 PM To: mamedev/mame Cc: Aaron Giles; Assign Subject: Re: [mamedev/mame] mips3 drc : missing label for branch destination, destination in unmapped page (#2191) Changing mips3_device::generate_delay_slot_and_branch to check if the targetpc is mapped before generating a JMP and instead generating a HASHJMP, fixes the issue with no label found, as it no longer will generate something that is looking for the label. /* update the cycles and jump through the hash table to the target */ if (desc->targetpc != BRANCH_TARGET_DYNAMIC) { generate_update_cycles(block, &compiler_temp, desc->targetpc, true); // <subtract cycles> offs_t temp_target = desc->targetpc; if ((desc->flags & OPFLAG_INTRABLOCK_BRANCH) && (memory_translate(AS_PROGRAM, TRANSLATE_FETCH, temp_target))) UML_JMP(block, desc->targetpc | 0x80000000); // jmp desc->targetpc | 0x80000000 else UML_HASHJMP(block, m_core->mode, desc->targetpc, *m_nocode); // hashjmp <mode>,desc->targetpc,nocode Now, the issue is execution reaches the branch as 15002FFC and checks for a tlb_mismatch at 15003000, but the tlb_mismatch recovers the pc as 15002FFD and checks that against the TLB, when it needs to recover the actual address 15003000 to check against the TLB. With 15002FFD it does not see the address (15003000) as unmapped and fails to generate a TLB exception. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub<#2191 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AGDTc0PKC9ZgDpAR6xyAridzpcancnnJks5rrp9kgaJpZM4MpqCO>.

[Happy-yappH]

Yes, the solution you proposed only modifies the most recently compiled branch to this target. So it catches the branch at 15002FFC but not the one at 15002FEC.