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

The Sad State of Debug Performance in C++

vittorioromeo.info

Post reply on HN
Print view View original

11–20 of 111 posts

Re: The Sad State of Debug Performance in C++

#11

Post by fartsucker69 »

humanrebar wrote: post #9

Have any multibillion dollar game (etc.) companies invested any resources into debug build modes in the open source compilers they develop with? Seems like it should be trivial to tie team productivity rates to quality of the debug experience.

That proposition seems risky. If the compiler owners don't accept your pull requests, you risk having to maintain a fork with your changes indefinitely.

Also, I suspect like 95%+ of development at game dev studios happens in MSVC. Nothing to change there.

Unfortunately pestering the compiler devs about this seems like the optimal approach lol

Re: The Sad State of Debug Performance in C++

#12

Post by adrian_b »

usefulcat wrote: post #8
glandium wrote: post #2

> Even if -Og was ubiquitous, it is still suboptimal to -O0: it can still inline code a bit too aggressively for an effective debugging session. IMO, the problem is not so much the inlining, but the sad state of the optimization passes losing track of many things and producing useless debug info.

It's not just inlining. With -Og (clang or gcc), the debugger frequently can't even tell me the value of function arguments because they've been "optimized out".

While I agree with you and with the OP and I have also been sometimes annoyed by this kind of debugger messages, the more universal solution than wanting an improved debugger is to rely for debugging on some form of progress and error logging in your program, which will work at any optimization level.

Adding such debugging aids in your program may need some extra work, but it also functions in all cases when using the debugger is hopeless, e.g. for concurrent programs or other programs that depend on real-time interactions which prevent the use of breakpoints.

Re: The Sad State of Debug Performance in C++

#14

Post by tialaramex »

DannyBee wrote: post #5
glandium wrote: post #2

> Even if -Og was ubiquitous, it is still suboptimal to -O0: it can still inline code a bit too aggressively for an effective debugging session. IMO, the problem is not so much the inlining, but the sad state of the optimization passes losing track of many things and producing useless debug info.

Eons ago, i wrote a lot of the first version of debug location tracking/location list tracking in GCC, and the support for evaluating them in GDB (plenty of others came along and improved it nearly instantly - it thankfully did not last long alone ;P). I have spent, over the years, an amazing amount of time on trying to improve optimized-code debug info. You could and should improve the optimization passes, but at va…

> they aren't (again, AFAIK) doing anything about it other than writing blog posts about how the language is mean to them, and filing bugs that compilers are mean to them.

There are people from that industry or adjacent industries writing other languages. Most obviously Jai (Jonathan Blow's language, Jonathan did "Braid" and "The Witness") but you could also argue for Ginger Bill's Odin. I suppose in this context it will be interesting to see whether the debug story is any better in these languages (neither is yet finished).

Re: The Sad State of Debug Performance in C++

#15

Post by cyber_kinetist »

BenFrantzDale wrote: post #4

It’s always nice to understand more about why game developers do the weird things they do. I always buried and run in “RelWithDebInfo”, then if I really need it, I’ll throw `#pragma clang optimize off` around the code that the debugger can’t see into.

Really nice tip to know! I've also struggled a lot with slow debug performance, so this will be very handy when I know there's a bug somewhere in a specific region but can't pinpoint exactly where.

Re: The Sad State of Debug Performance in C++

#16

Post by Decabytes »

humanrebar wrote: post #9

Have any multibillion dollar game (etc.) companies invested any resources into debug build modes in the open source compilers they develop with? Seems like it should be trivial to tie team productivity rates to quality of the debug experience.

Not exactly what you were asking, but RAD tried to build a debugger for Linux^1, but the project died. I’ve heard the people at RAD described as hard core old school programmers, so if they struggled with this it must just be a hard problem

1. http://www.radgametools.com/debug.htm

Re: The Sad State of Debug Performance in C++

#17

Post by [deleted] »

fartsucker69 wrote: post #11
humanrebar wrote: post #9

Have any multibillion dollar game (etc.) companies invested any resources into debug build modes in the open source compilers they develop with? Seems like it should be trivial to tie team productivity rates to quality of the debug experience.

That proposition seems risky. If the compiler owners don't accept your pull requests, you risk having to maintain a fork with your changes indefinitely. Also, I suspect like 95%+ of development at game dev studios happens in MSVC. Nothing to change there. Unfortunately pestering the compiler devs about this seems like the optimal approach lol

[deleted]

Re: The Sad State of Debug Performance in C++

#18

Post by cyber_kinetist »

humanrebar wrote: post #9

Have any multibillion dollar game (etc.) companies invested any resources into debug build modes in the open source compilers they develop with? Seems like it should be trivial to tie team productivity rates to quality of the debug experience.

For PS3 development it seems that the devs were forced to use a fork of GCC made to support the notorious Cell architecture (some info from here: https://www.copetti.org/writings/consoles/playstation-3/). Not sure about the NDA details but I would believe contributing to the compiler would have been difficult (and would have not really landed in the GCC trunk anyway).

For PS4 and later Sony used an LLVM fork for their toolchain, so now they don't even have the obligation to share their compiler code. Maybe some improvements to LLVM will "naturally" go back to the devkit, but it's not really a good situation for open-source contribution.

Not sure how it went for the XBox lineups though (Probably it used MSVC, since it's from Microsoft?). Since console development is mired up in NDAs there's not that much public info about it.

Re: The Sad State of Debug Performance in C++

#20

Post by kevingadd »

humanrebar wrote: post #9

Have any multibillion dollar game (etc.) companies invested any resources into debug build modes in the open source compilers they develop with? Seems like it should be trivial to tie team productivity rates to quality of the debug experience.

If you're developing for games consoles, you're probably stuck using a specific revision of the compiler offered by the platform owner, even if it happens to be clang under the hood. In some cases their certification requirements entirely prohibit using other compilers.

So improved debug performance is probably not in the cards unless you change your code to work around compiler issues.

Post reply on HN