Day 3 : 10 June 2022 : Visual Code Debugging on macOS and Linux

 

My 100 Daze of Code

https://github.com/davidjwalling/100-days-of-code

Visual Code Debugging on macOS and Linux

We have at least two low-level debugging options on macOS, gdb and lldb. While gdb can be used, it requires that the gdb program be code-signed. Seemingly, from posts on the interwebs, this process differs across more recent macOS versions. And, even then, it is clearly not effective for some users. I prefer using lldb on macOS. However, with this approach, an additional extension is installed in Visual Code to provide the "glue" between lldb itself and Visual Code. More details on that below.

Today, I'll also provide an alternate way to organize the source code and consolidate the three existing CMakeLists.txt files into one. Where before I had compartmentalized the source into library and executable folders, libava and ava, respectively, I've combined everything at the project root level to demonstrate a simplified organization.

When debugging in Visual Code, the launch.json file can be used to define multiple debugging configurations for different operating system environments. For example, we'll use gdb on Linux but lldb on macOS. What I'm curious about here is that Visual Code seems to warn on paths and identifiers not known on a specific platform. For example, I can define two configurations in launch.json, one for macOS and one for Linux. But, on Linux, VS Code warns on macOS paths not found. This may take further research.

Lastly, and, hopefully, no one will mind this, I've begun to pare down the contents of the repo to include only files necessary to this project. I'll use this blog to reflect progress and thoughts.

Revisiting Visual Code Extensions

For Linux, only the "C/C++ Extension Pack" extension for Visual Code had been installed. This works well for Linux, since gdb debugging is supported inherently. But on macOS, which uses lldb, we use an additional extension, "CodeLLDB" by Vadim Chugunov. There are other lldb extensions, but I had the best success with this one and I think that is reflected in the download counts.

Note that "C/C++ Extension Pack" is in fact a set of six extensions, at least at this time. With CodeLLDB added, the total installed extensions on macOS look like this now.


Simplify Code Organization

Up to now, we've organized source into library and executable folders, each with its own cmake file. Here, we'll use a much simpler, flatter organization and merge the three CMakeLists.txt files into one.


Notice that we now have two files in the .vscode folder. The first, "c_cpp_properties.json," defines information about our platform configurations. The second, "launch.json," now contains debugging information for both the macOS and Linux platforms.

c_cpp_properties.json


launch.json

We now have gdb and lldb configurations in launch.json for our debugging.


Consolidated CMakeLists.txt

The consolidated "CMakeLists.txt" file defines both the library (libava) and the executable (ava). It also defines both build and install operations.


Reconfirm Build on Linux

The build operation is the same as before, only performed at the repository base. Note, however, that we now include the "-DCMAKE_BUILD_TYPE=Debug" option when building with cmake.


Reconfirm Debugging on Linux

After our updates, repeat our debugging on Linux so that we can confirm that our headers are found properly and that single-step debugging is operational. Note that we're running the "(gdb) Launch" debugging configuration defined in launch.json.


Confirm Build on macOS

Update the repository and "git pull" again on macOS to update the local repository on our Mac. Follow the same build instructions.

If you look closely, you'll see I added an "xcrun xcodebuild" statement to suppress those annoying xcodebuild warnings.


Debug with Visual Code on macOS

Set a breakpoint on the IDriver declaration in main.cpp. This is because we set CodeLLDB's "stopOnEntry" attribute to false. When set to true, I saw that it stopped at the dylib loader instead of the main routine.


Step into until the terminal output is shown. Then "F5" to complete.








Comments

Post a Comment

Popular posts from this blog

Day 12 : 19 June 2022 : Adding Windows Service Logic

Image
My 100 Daze of Code https://github.com/davidjwalling/100-days-of-code #12 : Adding Windows Service Logic Today, we'll add some Win32 API logic in Ava to install, uninstall and run as a service on Windows. We'll add logic in Driver::Service that check if the program was started with the "service" argument as the first program argument. If so, the Service Control Manager will be invoked to start the program as a service. We'll also check for "install" and "uninstall" program arguments and handle these with logic that installs and uninstalls the program, respectively. In a later post, we'll do the equivalent on Linux and macOS and show how to enable Ava to run as a daemon configured in sysctl. Nowadays there are shortcut methods to install and run an executable as a service on Windows. But I prefer to illustrate the APIs that make this work. Some Code Refactoring Up to now we've been using a pointer-to-implementation (pimpl) method for exp...
Read more

Day 5 : 12 June 2022 : CMake on Windows

Image
 My 100 Daze of Code https://github.com/davidjwalling/100-days-of-code Day 5 : 12 June 2022 : CMake on Windows So far, we've seen using CMake on Linux and MacOS. Also, we've looked at native compilation on Windows using Visual Studio (VS). Today, we'll look at using CMake on Windows. I decided to devote an entire day (hour) to this because there are several ways to invoke CMake on Windows, using different "Generators". A generator will write the inputs to the native build tools. But Wait, There's More ... Before heading to CMake, I wanted to first point out that VS' native tools can build just fine without using CMake, of course. To build using "msbuild," open an x64 Native Tools Command Prompt for Visual Studio - this is provided when VS is installed. Invoke msbuild and pass the solution name and the desired platform and configuration. msbuild ava.sln /p:Platform=x64 /p:Configuration=Debug Repeat for Debug and Release configurations for Win32 an...
Read more

Day 11: 18 June 2022 : Handling Program Arguments

Image
My 100 Daze of Code https://github.com/davidjwalling/100-days-of-code #11 : Handling Program Arguments Up to now we've been carrying around Ava's program argument count (argc) and value array (argv) into a Configure method. Now it's time to start doing something with those values. We'll define four program settings that can be set by passing program arguments: the logging level, path, prefix and suffix, and show examples of using them. Logging Parameter Storage The singleton theLog is instantiated inside the Ava library (libava). Default values for several logging parameters are set by the Log::Init method, which is called both by the Log class constructor and the destructor, by way of the Reset method, so that runtime values are not left in deallocated storage on operating systems that do not automatically clear memory upon deallocation. Logging Parameter Symbols We use namespaces and enums to define symbolic names for the logging parameters so that we have a single lo...
Read more