Debugging C in VS Code

Knowing how to use a debugger for the tools that you use is one of the best investments you can make.

Debuggers help you explore the state of your program. They provide feedback much faster than other debugging methods, like print statements. They also allow you to see everything, whereas a print statement will only show what you choose to print. This can be very helpful when part of a program that you expect to be working correctly is actually misbehaving.

Advanced Operating Systems, the course that I’m currently taking for my Masters are Georgia Tech, requires that you spend a fair bit of time working in C. C is a fine language, but it is very cumbersome to debug programs without a debugger. Save yourself some frustration and set your debugging environment up before you start working on your program.

VS Code makes this very easy.

Setup

  1. Install the C/C++ extension

  2. Open up the “Run and Debug” pane

  3. Click the cog icon to open up the launch.json file which contains your debugging configuration

  4. Copy this into the launch.json file:

    {
      "name": "debug",
      "type": "cppdbg",
      "request": "launch",
      "program": "${workspaceFolder}/<path to your compiled binary>",
      "args": ["<your program arguments>"],
      "stopAtEntry": false,
      "cwd": "${fileDirname}",
      "environment": [],
      "externalConsole": false,
      "MIMode": "gdb",
      "setupCommands": [
        {
          "description": "Enable pretty-printing for gdb",
          "text": "-enable-pretty-printing",
          "ignoreFailures": true
        },
        {
          "description": "Set Disassembly Flavor to Intel",
          "text": "-gdb-set disassembly-flavor intel",
          "ignoreFailures": true
        }
      ]
    }
    
  5. Save the file and click on “Start Debugging”

VS Code will launch your binary and attach a debuggger. You can do all of the usual debugger things like set breakpoints and inspect program state.

Posts from blogs I like

Much ado about "nothing"

Author's note Originally, I was gonna wait a bit before writing this. I had intended this to be written and published in a few weeks after the NixOS foundation board had time to react and attempt to control the damage from whatever the fuck has been going on over there. I just don't care at this point. I need this out of my head and off of my chest. I would also like to have made this a video of some kind to make it more personal (mostly so you can hear my voice and intonation/emotio…

via Xe Iaso's blog April 27, 2024

Copyleft licenses are not “restrictive”

One may observe an axis, or a “spectrum”, along which free and open source software licenses can be organized, where one end is “permissive” and the other end is “copyleft”. It is important to acknowledge, however, that though copyleft can be found at the opposite end of an axis with respect to permissive, it is not synonymous with the linguistic antonym of permissive – that is, copyleft licenses are not “restrictive” by comparison with permissive licenses. Aside: Free software is not synonymous with copyle…

via Drew DeVault's blog April 19, 2024

How web bloat impacts users with slow devices

In 2017, we looked at how web bloat affects users with slow connections. Even in the U.S., many users didn't have broadband speeds, making much of the web difficult to use. It's still the case that many users don't have broadband speeds, both inside and outside of the U.S. and that much of the modern web isn't usable for people with slow internet, but the exponential increase in bandwidth (Nielsen suggests this is 50% per year for high-end connections) has outpaced web bloat for typical sites, making this l…

via danluu.com March 16, 2024