Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GCC gOlogy: studying the impact of optimizations on debugging

fsfla.org

Post reply on HN
Print view View original

11–20 of 32 posts

Re: GCC gOlogy: studying the impact of optimizations on debugging

#11

Post by john_moscow »

khitchdee wrote: post #9

If you approach debugging in a very minimalist way, you should never use a debugger because it only serves to complicate things using the I/O subsystem to debug your program is a far more efficient way to debug. If you do things this way, you orthogonalize the optimization side of your compiler from the mess created by trying to assist the debugging process via the rather complex and intrusive (from the compiler's pe…

except it's much faster to put a few breakpoints than to recompile your code each time you want to add/remove a logging statement.

Re: GCC gOlogy: studying the impact of optimizations on debugging

#12

Post by tempodox »

khitchdee wrote: post #9

If you approach debugging in a very minimalist way, you should never use a debugger because it only serves to complicate things using the I/O subsystem to debug your program is a far more efficient way to debug. If you do things this way, you orthogonalize the optimization side of your compiler from the mess created by trying to assist the debugging process via the rather complex and intrusive (from the compiler's pe…

You should never say “never”.

Re: GCC gOlogy: studying the impact of optimizations on debugging

#13

Post by DannyBee »

userbinator wrote: post #8

More times than I'd like, I've encountered GDB refusing to show the value of a variable, claiming it's "optimized away". No, it's sitting right there in a register, and I know that because I just stepped through, instruction-by-instruction, the code that computed its value. Fortunately it does not claim the register has been "optimized away" too, but the experience of debugging optimised code could definitely use a l…

(I wrote a bunch of gcc's initial support for optimized code debugging, as well as the initial associated gdb support for evaluating location lists and expressions, which is what makes this all work under the covers)

Given the invariant of "debug info does not affect optimization", you end up with plenty of cases where your only possible choices are "give the user a possibly wrong value for the variable" or "say the value does not exist anymore".

Most of the time, the latter is done instead of the former.

You also unfortunately cannot just mark them so the debugger tells you "this may be wrong, it may be right, good luck".

Historically, compilers tried doing the former, users complained enough that they switched to doing the latter.

Re: GCC gOlogy: studying the impact of optimizations on debugging

#14

Post by mehrdadn »

userbinator wrote: post #8

More times than I'd like, I've encountered GDB refusing to show the value of a variable, claiming it's "optimized away". No, it's sitting right there in a register, and I know that because I just stepped through, instruction-by-instruction, the code that computed its value. Fortunately it does not claim the register has been "optimized away" too, but the experience of debugging optimised code could definitely use a l…

Regarding MSVC, just if you don't know already, you might want to try /Zo (formerly /d2Zi+). [1]

[1] https://msdn.microsoft.com/en-us/library/dn785163.aspx

Re: GCC gOlogy: studying the impact of optimizations on debugging

#15

Post by mehrdadn »

DannyBee wrote: post #13
userbinator wrote: post #8

More times than I'd like, I've encountered GDB refusing to show the value of a variable, claiming it's "optimized away". No, it's sitting right there in a register, and I know that because I just stepped through, instruction-by-instruction, the code that computed its value. Fortunately it does not claim the register has been "optimized away" too, but the experience of debugging optimised code could definitely use a l…

(I wrote a bunch of gcc's initial support for optimized code debugging, as well as the initial associated gdb support for evaluating location lists and expressions, which is what makes this all work under the covers) Given the invariant of "debug info does not affect optimization", you end up with plenty of cases where your only possible choices are "give the user a possibly wrong value for the variable" or "say the…

I wonder if the error message could just be better. Instead of using the excuse that the variable has been "optimized away", maybe gdb should just say it "cannot determine variable value due to optimization".

Re: GCC gOlogy: studying the impact of optimizations on debugging

#16

Post by speps »

caf wrote: post #10

What I'd appreciate is if GDB, when stopped during execution, could show _all_ of the source statements that are currently 'in progress' (for the common case under optimisation where the execution of several source statements are interleaved). I don't know how feasible that is, though.

Visual Studio has something called "Parallel Stacks" [1] which shows a graph of all the stacks of every thread of the application. It's very powerful when debugging multithreaded code.

[1] https://docs.microsoft.com/en-us/visualstudio/debugger/using...

Re: GCC gOlogy: studying the impact of optimizations on debugging

#17

Post by Serow225 »

mehrdadn wrote: post #14
userbinator wrote: post #8

More times than I'd like, I've encountered GDB refusing to show the value of a variable, claiming it's "optimized away". No, it's sitting right there in a register, and I know that because I just stepped through, instruction-by-instruction, the code that computed its value. Fortunately it does not claim the register has been "optimized away" too, but the experience of debugging optimised code could definitely use a l…

Regarding MSVC, just if you don't know already, you might want to try /Zo (formerly /d2Zi+). [1] [1] https://msdn.microsoft.com/en-us/library/dn785163.aspx

Thanks!

Re: GCC gOlogy: studying the impact of optimizations on debugging

#18

Post by saagarjha »

mehrdadn wrote: post #15
DannyBee wrote: post #13

Earlier quoted context omitted.

(I wrote a bunch of gcc's initial support for optimized code debugging, as well as the initial associated gdb support for evaluating location lists and expressions, which is what makes this all work under the covers) Given the invariant of "debug info does not affect optimization", you end up with plenty of cases where your only possible choices are "give the user a possibly wrong value for the variable" or "say the…

I wonder if the error message could just be better. Instead of using the excuse that the variable has been "optimized away", maybe gdb should just say it "cannot determine variable value due to optimization".

Or even: this variable has likely been optimized away, but you might still find it in $rax.

Re: GCC gOlogy: studying the impact of optimizations on debugging

#19

Post by saagarjha »

caf wrote: post #10

What I'd appreciate is if GDB, when stopped during execution, could show _all_ of the source statements that are currently 'in progress' (for the common case under optimisation where the execution of several source statements are interleaved). I don't know how feasible that is, though.

LLDB does this, and it lets you jump between threads. I’m not sure if GDB supports this.

Re: GCC gOlogy: studying the impact of optimizations on debugging

#20

Post by elgis »

khitchdee wrote: post #9

If you approach debugging in a very minimalist way, you should never use a debugger because it only serves to complicate things using the I/O subsystem to debug your program is a far more efficient way to debug. If you do things this way, you orthogonalize the optimization side of your compiler from the mess created by trying to assist the debugging process via the rather complex and intrusive (from the compiler's pe…

sometimes you might not have even printf available (very low-level software comes to mind) so you're limited to using registers. Without a debugger it would be a nightmare.
Post reply on HN