Our great sponsors
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
You may already have found some resources related to VSCode around, like this repository and this article. The launch.json files could be adapter to work with dap-launch (more on that later), but would require some manual work because of several smaller issues (one of them being that Emacs does not support VSCode tasks.json files at the moment). Both of them also seem to require you to copy-paste the launch.json files, and edit them with corrected paths each time (see how you can avoid that in Emacs at the end!).
No matter which editor you debug in, the workflow is about the same. You will need DevkitPro gba-dev and an emulator like mGBA. If you want to familiarize yourself with some C code for GBA, as well as Makefiles with CFlags and other build options, there is an example repo you can check out :)
No matter which editor you debug in, the workflow is about the same. You will need DevkitPro gba-dev and an emulator like mGBA. If you want to familiarize yourself with some C code for GBA, as well as Makefiles with CFlags and other build options, there is an example repo you can check out :)
We will use dap-mode with the dap-gdb-lldb option here. Under the hood, it uses the debug adapter from the Native Debug VSCode extension. Configuring it is described on the dap-mode webpages. After we have configured dap-mode, we could in theory reuse the launch.json configurations from the VSCode related articles above. That will require that you also use lsp-mode, as dap-launch depends on the lsp-workspace-root function and will not resolve when lsp-mode is not used. I don't use lsp-mode with C (company-clang and company-c-headers provide what I need), so the next logical solution would be to create a debug template ourselves:
You could just do it like this without any editor, but your debugging will then happen in the command line, and you will have to remember gdbs commands. This is not as tedious as it sounds, but many of us prefer to see the breakpoints happening, as well as the state, directly in our editors. Many editors therefore provide either a gdb interface, or can interact with it using a debug adapter. You can use debug adapters in VSCode through various plugins, in Emacs with dap-mode, in Vim with Vimspector, and probably in other editors as well. What is written here should be transferable to other editors.
We will use dap-mode with the dap-gdb-lldb option here. Under the hood, it uses the debug adapter from the Native Debug VSCode extension. Configuring it is described on the dap-mode webpages. After we have configured dap-mode, we could in theory reuse the launch.json configurations from the VSCode related articles above. That will require that you also use lsp-mode, as dap-launch depends on the lsp-workspace-root function and will not resolve when lsp-mode is not used. I don't use lsp-mode with C (company-clang and company-c-headers provide what I need), so the next logical solution would be to create a debug template ourselves:
The solutions above entails some manual work, and that lead me to automate it. Wouldn't it be nice to just run one simple command, and then everything compiles and your debug process just automatically begin? That's exactly what I was thinking, so I created a simple Emacs extension. If you use a Makefile to build, and configure the path to mGBA and DevkitARMs gdb, you can debug a GBA program directly with M-x gba-debug-program. No need to compile manually, run mGBA manually or anything else!