acaca4188e
* 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. |
||
|---|---|---|
| .appveyor | ||
| .github | ||
| .travis | ||
| CMakeModules | ||
| dist | ||
| externals | ||
| hooks | ||
| src | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmodules | ||
| .travis.yml | ||
| CMakeLists.txt | ||
| CONTRIBUTING.md | ||
| Doxyfile | ||
| README.md | ||
| appveyor.yml | ||
| bitrise.yml | ||
| keys.tar.enc | ||
| license.txt | ||
README.md
BEFORE FILING AN ISSUE, READ THE RELEVANT SECTION IN THE CONTRIBUTING FILE!!!
Citra
Citra is an experimental open-source Nintendo 3DS emulator/debugger written in C++. It is written with portability in mind, with builds actively maintained for Windows, Linux and macOS.
Citra emulates a subset of 3DS hardware and therefore is useful for running/debugging homebrew applications, and it is also able to run many commercial games! Some of these do not run at a playable state, but we are working every day to advance the project forward. (Playable here means compatibility of at least "Okay" on our game compatibility list.)
Citra is licensed under the GPLv2 (or any later version). Refer to the license.txt file included. Please read the FAQ before getting started with the project.
Check out our website!
For development discussion, please join us at #citra-dev on freenode.
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 in the forum in order to know about the current state of the emulator because the TODO list isn't maintained anymore.
If you want to contribute to the user interface translation, please checkout citra project on transifex. We centralize the translation work there, and periodically upstream translation.
Building
- Windows: Windows Build
- Linux: Linux Build
- macOS: macOS Build
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 Citra. Any donations received will go towards things like:
- 3DS consoles for developers to explore the hardware
- 3DS games for testing
- Any equipment required for homebrew
- Infrastructure setup
- Eventually 3D displays to get proper 3D output working
We also more than gladly accept used 3DS consoles, preferably ones with firmware 4.5 or lower! If you would like to give yours away, don't hesitate to join our IRC channel #citra on Freenode and talk to neobrain or bunnei. Mind you, IRC is slow-paced, so it might be a while until people reply. If you're in a hurry you can just leave contact details in the channel or via private message and we'll get back to you.