Skip to content

LLVM backend does not sustain execution on a DOL with code injected into former padding #27

Description

@dougchansan

Splitting this out of #20, at low priority.

The Colosseum extraction we had been benchmarking carries a widescreen mod in main.dol: 0x800A3930 has fmr f29,f2 replaced with b 0x80005300, and three instructions are injected at 0x80005300-0x80005308, an address range that is zero padding in a clean DOL.

The C backend copes with this. The LLVM backend does not.

On the modded DOL the LLVM arm does not sustain execution -- from a savestate it stops advancing frames at a deterministic point with the guest CPU at ~6% of realtime, while the C backend runs the same state normally. On a clean DOL neither backend has any problem, and the LLVM backend runs the title at a locked 60 fps.

This does not affect the shipping game, so it is not urgent. It matters if the widescreen mod is meant to be supported, and it may point at something generally useful: how the LLVM backend treats code discovered in regions that were zero-filled in the original image, and whether such code is reached only through a patched branch it may not have analysed as a call target.

Reproduction, if wanted:

  • modded: games/pkmn-colo-recomp/extracted/Pokemon-Colosseum-USA
  • clean: games/pkmn-colo-recomp/extracted/Colo-Fresh
  • the two differ at 0x80005300, 0x80005304, 0x80005308, 0x800A3930

Note that savestates are only valid against a module built from the same DOL, so a modded-DOL repro needs states captured on the modded DOL.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Status
    Todo

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions