On Mon, 2 Dec 2024 at 20:09, Pierrick Bouvier <pierrick.bouv...@linaro.org> wrote: > > On 12/2/24 11:56, Peter Maydell wrote: > > On Mon, 2 Dec 2024 at 18:36, Pierrick Bouvier > > <pierrick.bouv...@linaro.org> wrote: > >> Maybe our enable-debug should produced optimized builds by default, and > >> we could have a new --enable-debug-unopt for the "I need to use a > >> debugger" use case. Would save a lot of time for devs, and in CI where > >> minutes are precious. > > > > The whole point of --enable-debug is "I might need to use a debugger" > > (or a sanitizer, or anything else where you care about debug info). > > If you want the optimized builds, that's the default. > > > > It seems like we associate debug info to "I might need to use a > debugger". But, it's not the only use case. > Sanitizers for example, are usable with optimizations enabled as well > (with some caveats, as some errors might be optimized out).
Yes, it's the caveats that are the problem. If compilers supported an optimization mode that guaranteed not to break the debug illusion for backtracing, interactive debug, etc, then we could use it. But the best they do is -O0, so that's what we use. (-Og sounds like it ought to be what we want, but unfortunately it still leaves you with "value optimized out" errors in debuggers, so it's no good.) > I don't have anything against what --enable-debug does, but supporting > this for tests (and CI) because people *might* use it is a mistake IMHO. > It's an opinion beyond the current series use case. If your test is hitting the timeouts for --enable-debug on a local dev machine then it has a high chance of hitting the timeouts in CI in a non-debug build because of the "noisy neighbour" problem where a CI job runs massively slower than usual. The fix is to make sure the timeout is high enough not to be hit in a debug build, and wherever possible to have tests that are cut down so they have short runtimes. thanks -- PMM
