GCC option that can cause trouble when debugging with GDB
Asked Answered
A

2

8

I was wondering if I can get a list of gcc option that can cause gdb to behave strange.

Of course, we all know that using optimization options (-O3 for instance) causes weird behaviour in gdb, but what are the other options that can have such impact?

(I'm currently trying to run an mpeg2 decoder in gdb and I get weird behaviour even after removing optimization flags ...)

Aryan answered 11/2, 2010 at 17:16 Comment(5)
Describe weird. Did you add -ggdb? And most important: Write which options you still use.Charlottetown
Only used -g and -g3 already. The weird behaviour in my case is something like this : a function definition begins at line 654, 'n' then jumps to line 765, another 'n' jump back to line 654 and so on for 4 or 5 times, of course, line 765 isn't the one that should be the next ... But even if I'm looking for the flag that causes this problem right now, I'm curious of different options that can cause strange behavior more generally.Aryan
For the option I'm still using, there's quiet a lot, I didn't post them in my question and make it more general instead.Aryan
Generally you are better off with a more specific question. Sounds like inlineing or loop unrolling.Charlottetown
I'll post remaining flags tomorrow at work then.Aryan
L
9

I think it's difficult to say what flags you should't use when calling gcc for debugging. The gcc docs note that the default debug flags for a libstdc++ build are -g and -O2, and using -g -O0 -fno-inline disables any optimization and function inlining.

In my opinion, if you really want to guaratee that nothing will mess your debugging process, you just have to compile with -g -O0 -fno-inline flags.

Lustral answered 11/2, 2010 at 20:5 Comment(3)
what happen if you have at the same time -O3 flag, some other flag, and "-g -O0 -fno-inline" ?Nary
I made a simple program and use -O3 -g -O0 -fno-inline -S and I had the same output of -g -O0 -fno-inline -S. But with -g -O0 -fno-inline -O3 -S the output was different, in this case, the assembly code with -O3 was bigger than the code generated without -O3. I don`t know the implications of this result yet.Lustral
No surprise, the -O0 overwrites the -O3 in the first case. The gcc manpage says: "If you use multiple -O options, with or without level numbers, the last such option is the one that is effective."Idea
T
0

As stated in GCC documentation, you should use -Og:

-Og

Optimize debugging experience. -Og enables optimizations that do not interfere with debugging. It should be the optimization level of choice for the standard edit-compile-debug cycle, offering a reasonable level of optimization while maintaining fast compilation and a good debugging experience.

It also describes every optmization flag and how it might affect debugging.

Theresatherese answered 1/12, 2015 at 18:1 Comment(2)
In principle yes, in practice -O0 might be preferablePeking
-Og has some issues e.g. #31436271Perzan

© 2022 - 2024 — McMap. All rights reserved.