Why doesn't gdb see line numbers in my plugin?

Development
1

When I hit an access violation, and do bt in the debugger, I see the names of my functions, but it’s only in the rack code that I see line numbers. How do I make gbd see my line numbers?

2

Does your makefile include -g in the cc options?

3

No, and I’ll bet that’s important :wink:

my makefile comes from the (old) VCV “template” plugin, and does this:

CFLAGS +=
CXXFLAGS +=

So I’m just using what’s in VCV’s plugin.mk. can I use -g all the time, or should I only use it in “debug” builds?

And thanks!

4

I would restrict it to debug builds, but I thinks it’s safe to use all the time.

You’d have to check the compiler documentation, but I don’t believe it prevents optimisations. It will make the object files bigger.

5

https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#Debugging-Options

6

oh, interesting. I’m going to guess that it gets stripped out when you do a make dist?

7

If I remember the make recipe for dist includes strip

8

yep

9

In order to get debugging working in the SDK I had to make two changes.

First, in compile.mk I removed the -O3 flag:

diff --git a/compile.mk b/compile.mk
index 96ea4b8..1926ccf 100644
--- a/compile.mk
+++ b/compile.mk
@@ -12,7 +12,7 @@ FLAGS += -MMD -MP
 # Debugger symbols. These are removed with `strip`.
 FLAGS += -g
 # Optimization
-FLAGS += -O3 -march=nocona -funsafe-math-optimizations
+FLAGS += -march=nocona -funsafe-math-optimizations
 # Warnings
 FLAGS += -Wall -Wextra -Wno-unused-parameter
 # C++ standard

And then in plugin.mk the stripcommand was removed:

diff --git a/plugin.mk b/plugin.mk
index 723f525..f44e1a1 100644
--- a/plugin.mk
+++ b/plugin.mk
@@ -59,6 +59,7 @@ dist: all
 ifdef ARCH_MAC
        $(STRIP) -S dist/"$(SLUG)"/$(TARGET)
 else
+       # $(STRIP) -s dist/"$(SLUG)"/$(TARGET)
        $(STRIP) -s dist/"$(SLUG)"/$(TARGET)
 endif
        @# Copy distributables

If I’m not mistaken the -g flag was already present, but the symbols were being stripped later.

10

-g should be compatible with -O3.

But aggressive optimization will often make for sections of very confusing line numbering, and the results can be less than useful

11

I found by debugger (gdb front-ended by VS Code) to be confused with -O3. Or at least it confused me!

1 Like
12

for sure. I’ve found that for my light use of bgf (basically getting stack traces for crash) it’s fine with -O3. But If I were doing single step debugging I know it would be a nightmare.