4 ms·

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

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.

jcranmer 8y ago
I think, after scrolling down to the bottom, it's meant to be a look at what passes are unnecessarily impairing debugging information.
- vanderZwan 8y ago
  So like an ultra-long bug report?
tom_ 8y ago
I used to send mails like this at work to people somewhat often, selecting mailing group according to subject. I'd typically have spent a while trying to figure something out, met with some success, and figured I might as well send a summary to anybody that could be remotely concerned. Maybe save somebody else the bother in future. Most of the time, nobody cared. (Which is fine, I never did this stuff for no reason, the write-up was typically beneficial for me personally, and if nobody else cared, that's OK by me.) But the odd one would prove useful and end up getting re-forwarded multiple times, and that happened often enough that I kept doing it. (I use the past tense because I do contract work these days, and that works differently.) Leaving aside the justification for this sort of thing in general, and moving on to why you might be interested in this particular note: suppose you'd always just built your code at one of either -O0 (shit code, but works well with any debugger), -Os (slightly less shit code, debugging probably tolerable) or -O2/-O3 (decent code, but debugging is a pain - and I always knew the assembly language for every target! The people that only knew C++ had a devil of a time). So this works, and you're used to it, and what better argument for anything could there possibly be. But you probably wondered whether you could do better, and with this in mind you've probably looked at the gcc manual and noted that there's this huge pile of other sub-options. What if you tweaked those, you wonder? Would that make things better? Would it make them worse? If you only had the time to investigate which would impede debugging, and which you could just pop into your debug build with impunity, safe in the knowledge that it wouldn't cause you any difficulty! If only you had the sort of more in-depth knowledge of compiler internals required to make this sort of judgement by yourself, rather than just go through the 500,000 combinations of options to try each one in turn! And/or if you only you had somebody on staff who could just try this stuff out and write you a summary! But you don't, and you don't, and you don't, and you have a product to finish anyway... So this document might at least be mildly interesting.
- cjhanks 8y ago
  I appreciate your comment and its perspective. I spend a lot of my time optimizing code switching between,01 and 03. I am genuinely very worried about the trade-off between optimization and pragmatism. At the same time, I am limited. This very useful analysis would help me a lot if it providied an executive summary. Non-linear debug builds are obviously harmful.
lxoliva 8y ago
the point was to document current shortcomings in debug info generation and identify opportunities for improvement. the executive summary is that there are many ;-)

jcranmer 8y ago

I think, after scrolling down to the bottom, it's meant to be a look at what passes are unnecessarily impairing debugging information.

vanderZwan 8y ago
So like an ultra-long bug report?

tom_ 8y ago

I used to send mails like this at work to people somewhat often, selecting mailing group according to subject. I'd typically have spent a while trying to figure something out, met with some success, and figured I might as well send a summary to anybody that could be remotely concerned. Maybe save somebody else the bother in future. Most of the time, nobody cared. (Which is fine, I never did this stuff for no reason, the write-up was typically beneficial for me personally, and if nobody else cared, that's OK by me.) But the odd one would prove useful and end up getting re-forwarded multiple times, and that happened often enough that I kept doing it. (I use the past tense because I do contract work these days, and that works differently.) Leaving aside the justification for this sort of thing in general, and moving on to why you might be interested in this particular note: suppose you'd always just built your code at one of either -O0 (shit code, but works well with any debugger), -Os (slightly less shit code, debugging probably tolerable) or -O2/-O3 (decent code, but debugging is a pain - and I always knew the assembly language for every target! The people that only knew C++ had a devil of a time). So this works, and you're used to it, and what better argument for anything could there possibly be. But you probably wondered whether you could do better, and with this in mind you've probably looked at the gcc manual and noted that there's this huge pile of other sub-options. What if you tweaked those, you wonder? Would that make things better? Would it make them worse? If you only had the time to investigate which would impede debugging, and which you could just pop into your debug build with impunity, safe in the knowledge that it wouldn't cause you any difficulty! If only you had the sort of more in-depth knowledge of compiler internals required to make this sort of judgement by yourself, rather than just go through the 500,000 combinations of options to try each one in turn! And/or if you only you had somebody on staff who could just try this stuff out and write you a summary! But you don't, and you don't, and you don't, and you have a product to finish anyway... So this document might at least be mildly interesting.

cjhanks 8y ago
I appreciate your comment and its perspective. I spend a lot of my time optimizing code switching between,01 and 03. I am genuinely very worried about the trade-off between optimization and pragmatism. At the same time, I am limited. This very useful analysis would help me a lot if it providied an executive summary. Non-linear debug builds are obviously harmful.

lxoliva 8y ago

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