Guidelines and HOWTOs/Debugging/Debugging symbols

Overview

Debugging symbols allow you to debug your application better. They are added to your binary by the compiler. For KDE software, you have to decide during the cmake step if you want debugging symbols or not. To compile your application with debugging symbols, use

cmake . -DCMAKE_BUILD_TYPE=debug

to compile it without debugging symbols, use

cmake . -DCMAKE_BUILD_TYPE=release

Depending on your decision, output generated with the command kDebug will also be (debug) or not be (release) added to your application.

Example app

As an example, let's write an application that crashes:

main.cpp

#include <QApplication>
#include <QCommandLineParser>
#include <KAboutData>
#include <KLocalizedString>
#include <KMessageBox>
#include <iostream>

int main (int argc, char *argv[])
{
    QApplication app(argc, argv);
    KLocalizedString::setApplicationDomain("tutorial1");
    

    KAboutData aboutData(
                         // The program name used internally. (componentName)
                         QStringLiteral("tutorial1"),
                         // A displayable program name string. (displayName)
                         i18n("Tutorial 1"),
                         // The program version string. (version)
                         QStringLiteral("1.0"),
                         // Short description of what the app does. (shortDescription)
                         i18n("Displays a KMessageBox popup"),
                         // The license this code is released under
                         KAboutLicense::GPL,
                         // Copyright Statement (copyrightStatement = QString())
                         i18n("(c) 2015"),
                         // Optional text shown in the About box.
                         // Can contain any information desired. (otherText)
                         i18n("Some text..."),
                         // The program homepage string. (homePageAddress = QString())
                         QStringLiteral("http://example.com/"),
                         // The bug report email address
                         // (bugsEmailAddress = QLatin1String("[email protected]")
                         QStringLiteral("[email protected]"));

    aboutData.addAuthor(i18n("Name"), i18n("Task"), QStringLiteral("[email protected]"),
                         QStringLiteral("http://your.website.com"), QStringLiteral("OSC Username"));

    KAboutData::setApplicationData(aboutData);

    QCommandLineParser parser;
    aboutData.setupCommandLine(&parser);
    parser.process(app);
    aboutData.processCommandLine(&parser);
    
    KGuiItem yesButton(i18n("Hello"), QString(),
                        i18n("This is a tooltip"),
                        i18n("This is a WhatsThis help text."));

    int* i;
    std::cout << "i is at " << i << " value " << *i << std::endl;
    i=(int*)0x0;
    std::cout << "i is at " << i << " value " << *i << std::endl;
    
    return KMessageBox::questionYesNo(0, i18n("Hello World"), i18n("Hello"), yesButton) 
        == KMessageBox::Yes? EXIT_SUCCESS: EXIT_FAILURE;
}

CMakeLists.txt

cmake_minimum_required(VERSION 3.0)

project (tutorial1)

set(QT_MIN_VERSION "5.3.0")
set(KF5_MIN_VERSION "5.2.0")

find_package(ECM 1.0.0 REQUIRED NO_MODULE)
set(CMAKE_MODULE_PATH ${ECM_MODULE_PATH} ${CMAKE_CURRENT_SOURCE_DIR}/cmake)

include(KDEInstallDirs)
include(KDECMakeSettings)
include(KDECompilerSettings NO_POLICY_SCOPE)
include(FeatureSummary)

# Find Qt modules
find_package(Qt5 ${QT_MIN_VERSION} CONFIG REQUIRED COMPONENTS
    Core    # QCommandLineParser, QStringLiteral
    Widgets # QApplication
)

# Find KDE modules
find_package(KF5 ${KF5_MIN_VERSION} REQUIRED COMPONENTS
    CoreAddons      # KAboutData
    I18n            # KLocalizedString
    WidgetsAddons   # KMessageBox
)

feature_summary(WHAT ALL INCLUDE_QUIET_PACKAGES FATAL_ON_MISSING_REQUIRED_PACKAGES)

set(tutorial1_SRCS main.cpp)
add_executable(tutorial1 ${tutorial1_SRCS})
target_link_libraries(tutorial1
    Qt5::Widgets
    KF5::CoreAddons
    KF5::I18n
    KF5::WidgetsAddons
)

install(TARGETS tutorial1 ${KDE_INSTALL_TARGETS_DEFAULT_ARGS})

Now let's compile this without debugging symbols:

cmake . -DCMAKE_BUILD_TYPE=release && make

We see that the resulting file is small:

$ ls -lh tutorial1
-rwxrwxr-x 1 user user 23K abr 18 10:36 tutorial1

With debugging symbols, the file is bigger:

cmake . -DCMAKE_BUILD_TYPE=debug && make
$ ls -lh tutorial1
-rwxrwxr-x 1 user user 577K abr 18 10:37 tutorial1

Backtraces

Now let's start the application and look at the backtrace. The execution of

cmake . -DCMAKE_BUILD_TYPE=release && make
./tutorial1
coredumpctl gdb

gives you that backtrace:

[...]
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000055f0ad8d660f in main ()
[Current thread is 1 (Thread 0x7f4cb1c78780 (LWP 4101741))]
(gdb) 

You can type "quit" and press return in order to exit gdb.

The debugging build and its execution:

cmake . -DCMAKE_BUILD_TYPE=debug && make
./tutorial1
coredumpctl gdb

gives you that backtrace:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000055c02d7a7b1b in main (argc=1, argv=0x7ffd33ca4768)
    at /home/user/test/main.cpp:53
53          std::cout << "i is at " << i << " value " << *i << std::endl;
[Current thread is 1 (Thread 0x7fe564d93780 (LWP 4111905))]
(gdb)

So you see: with debugging symbols, you see the line number and the line where the crash occurred. Without debugging symbols, you do not see that information.

Where are they?

Where are the debugging symbols stored? Use objdump -g to find out:

$ objdump -g tutorial1-release | wc -l
164
$ objdump -g tutorial1-debug | wc -l
148199

It is important to know that the code lines (in assembler) to be executed actually do not differ a lot. We see this when disassembling the code:

$ objdump -d tutorial1-debug | wc -l
1325
$ objdump -d tutorial1-release | wc -l
601

This gives us hope that there will be no major speed difference between a debug- and a release-version of a binary.

Speed implications

Now we have to remove the lines that cause the crash and the messagebox. After that, we can execute the program 100 times that way:

cmake . -DCMAKE_BUILD_TYPE=debug && make -j4
time for i in $(seq 1 1 100); do ./tutorial1; done

real    0m6.201s
user    0m4.368s
sys     0m1.320s

It lasts 6 seconds. Now with the release version:

cmake . -DCMAKE_BUILD_TYPE=release && make -j4
time for i in $(seq 1 1 100); do ./tutorial1; done

real    0m6.259s
user    0m4.368s
sys     0m1.328s

It also lasts 6 seconds. So the main difference is in the binaries size.

And make?

How does cmake propagate to make if a debug version is wanted? Do a

cmake . -DCMAKE_BUILD_TYPE=debug && make VERBOSE=1

You will find a difference during the link step. The parameters

-DNDEBUG -DQT_NO_DEBUG

are unique for the release version. There are further differences like the O3 optimization.