Nintendo Switch emulator
Go to file
Dimitri A 0e7ad1c367 gdbstub: Fix some bugs in IsMemoryBreak() and ServeBreak. Add workaround to let watchpoints break into GDB. (#4651)
* gdbstub: fix IsMemoryBreak() returning false while connected to client

As a result, the only existing codepath for a memory watchpoint hit to break into GDB (InterpeterMainLoop, GDB_BP_CHECK, ARMul_State::RecordBreak) is finally taken,
which exposes incorrect logic* in both RecordBreak and ServeBreak.

* a blank BreakpointAddress structure is passed, which sets r15 (PC) to NULL

* gdbstub: DynCom: default-initialize two members/vars used in conditionals

* gdbstub: DynCom: don't record memory watchpoint hits via RecordBreak()

For now, instead check for GDBStub::IsMemoryBreak() in InterpreterMainLoop and ServeBreak.

Fixes PC being set to a stale/unhit breakpoint address (often zero) when a memory watchpoint (rwatch, watch, awatch) is handled in ServeBreak() and generates a GDB trap.

Reasons for removing a call to RecordBreak() for memory watchpoints:
* The``breakpoint_data`` we pass is typed Execute or None. It describes the predicted next code breakpoint hit relative to PC;

* GDBStub::IsMemoryBreak() returns true if a recent Read/Write operation hit a watchpoint. It doesn't specify which in return, nor does it trace it anywhere. Thus, the only data we could give RecordBreak() is a placeholder BreakpointAddress at offset NULL and type Access. I found the idea silly, compared to simply relying on GDBStub::IsMemoryBreak().

There is currently no measure in the code that remembers the addresses (and types) of any watchpoints that were hit by an instruction, in order to send them to GDB as "extended stop information."
I'm considering an implementation for this.

* gdbstub: Change an ASSERT to DEBUG_ASSERT

I have never seen the (Reg[15] == last_bkpt.address) assert fail in practice, even after several weeks of (locally) developping various branches around GDB.  Only leave it inside Debug builds.
2019-03-15 16:31:06 +01:00
.appveyor
.github ISSUE_TEMPLATE: changes to make it more expressive and prevent low-quality issues 2019-01-22 21:52:59 +01:00
.travis travis: Bump macOS version to 10.14 2019-03-07 23:34:37 -05:00
CMakeModules shader/decode: Split memory and texture instructions decoding 2019-02-26 00:11:30 -03:00
dist
externals externals: Update cubeb to 6f2420de8f155b10330cf973900ac7bdbfee589d 2019-02-27 01:21:51 -05:00
hooks
src gdbstub: Fix some bugs in IsMemoryBreak() and ServeBreak. Add workaround to let watchpoints break into GDB. (#4651) 2019-03-15 16:31:06 +01:00
.gitattributes
.gitignore
.gitmodules gitmodules: Add Vulkan headers dependency 2019-02-12 18:33:02 -03:00
.travis.yml travis: Bump macOS version to 10.14 2019-03-07 23:34:37 -05:00
appveyor.yml
CMakeLists.txt cmake: Add Vulkan option 2019-02-12 18:33:02 -03:00
CONTRIBUTING.md
Doxyfile
license.txt
README.md Yuzu can render 3D. 2019-03-02 17:23:05 +01:00

yuzu emulator

Travis CI Build Status AppVeyor CI Build Status

yuzu is an experimental open-source emulator for the Nintendo Switch from the creators of Citra.

It is written in C++ with portability in mind, with builds actively maintained for Windows, Linux and macOS. The emulator is currently only useful for homebrew development and research purposes.

yuzu only emulates a subset of Switch hardware and therefore is generally only useful for running/debugging homebrew applications. At this time, yuzu cannot play any commercial games without major problems. yuzu can boot some games, to varying degrees of success.

yuzu is licensed under the GPLv2 (or any later version). Refer to the license.txt file included.

Check out our website!

For development discussion, please join us on Discord.

Development

Most of the development happens on GitHub. It's also where our central repository is hosted.

If you want to contribute please take a look at the Contributor's Guide and Developer Information. You should as well contact any of the developers on Discord in order to know about the current state of the emulator.

Building

Support

We happily accept monetary donations or donated games and hardware. Please see our donations page for more information on how you can contribute to yuzu. Any donations received will go towards things like:

  • Switch consoles to explore and reverse-engineer the hardware
  • Switch games for testing, reverse-engineering, and implementing new features
  • Web hosting and infrastructure setup
  • Software licenses (e.g. Visual Studio, IDA Pro, etc.)
  • Additional hardware (e.g. GPUs as-needed to improve rendering support, other peripherals to add support for, etc.)

We also more than gladly accept used Switch consoles, preferably ones with firmware 3.0.0 or lower! If you would like to give yours away, don't hesitate to join our Discord and talk to bunnei. You may also contact: donations@yuzu-emu.org.