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

21–30 of 32 posts

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

#21

Post by jcelerier »

john_moscow wrote: post #11
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.

> 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.

that reeaaallly depends. I had cases where adding a printf and recompiling would take mere seconds and a gdb startup on the order of 3 to 4 minutes because recompiling only changes one shared library while GDB has to load all of them.

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

#22

Post by kccqzy »

speps wrote: post #16
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...

I believe GP is not talking about thread parallelism, but rather the compiler-controlled instruction reordering. Compilers typically reorder instructions in the hope that it will improve performance. For example if you have v+=2, the compiler can choose to load v into a register, and then continue with the rest of the statements, and ten instructions later perform the actual addition and store it back into memory.

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

#23

Post by khitchdee »

elgis wrote: post #20
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.

Why would you ever need to go below the abstraction level of your high level language to debug.

If you're going down into registers, you're obviously debugging the wrong way.

You don't need printf's if you write directly to your screen which is easy to do.

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

#24

Post by khitchdee »

tempodox wrote: post #12
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”.

... and then never say never again

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

#25

Post by khitchdee »

john_moscow wrote: post #11
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.

If you don't use a debugger, you don't need an IDE either.

A text editor and a compiler is all you need.

That simplifies your programming interface a lot.

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

#26

Post by caf »

kccqzy wrote: post #22
speps wrote: post #16

Earlier quoted context omitted.

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...

I believe GP is not talking about thread parallelism, but rather the compiler-controlled instruction reordering. Compilers typically reorder instructions in the hope that it will improve performance. For example if you have v+=2, the compiler can choose to load v into a register, and then continue with the rest of the statements, and ten instructions later perform the actual addition and store it back into memory.

Yes, that's what I was referring to. When single-stepping such code you'll often see it skip backwards and forwards between the interleaved source statements.

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

#27

Post by nkurz »

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…

Could you clarify this comment a bit? Does GDB ever use current register contents to satisfy a request for a variable, or does it only use a value saved to the stack? That is, is the problem that you don't know when the register value is no longer valid, or that GDB doesn't actually associate the value with a register at all?

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

#28

Post by lxoliva »

cjhanks wrote: post #2

I kept reading and reading wondering, what is the point of this document? I make it 1/3rd through. It seems well informed, but it lacks any coherent structure. And throughout I couldn't deduce what the point was. Like a well educated rant.

the point was to document current shortcomings in debug info generation and identify opportunities for improvement. the executive summary is that there are many ;-)

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

#29

Post by elgis »

khitchdee wrote: post #23
elgis wrote: post #20

Earlier quoted context omitted.

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.

Why would you ever need to go below the abstraction level of your high level language to debug. If you're going down into registers, you're obviously debugging the wrong way. You don't need printf's if you write directly to your screen which is easy to do.

>Why would you ever need to go below the abstraction level of your high level language to debug.

I don't know what you mean by this. If you don't have f.ex. printf available you have to come up with something else.

>You don't need printf's if you write directly to your screen which is easy to do.

What if the hardware you're debugging doesn't have a screen?

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

#30

Post by khitchdee »

elgis wrote: post #29
khitchdee wrote: post #23

Earlier quoted context omitted.

Why would you ever need to go below the abstraction level of your high level language to debug. If you're going down into registers, you're obviously debugging the wrong way. You don't need printf's if you write directly to your screen which is easy to do.

>Why would you ever need to go below the abstraction level of your high level language to debug. I don't know what you mean by this. If you don't have f.ex. printf available you have to come up with something else. >You don't need printf's if you write directly to your screen which is easy to do. What if the hardware you're debugging doesn't have a screen?

Well, in that case you'll have to make do with whatever interface you are using that doesn't have a screen such as your existing debugger
Post reply on HN