On 11/6/24 09:40, Thomas Huth wrote:
On 06/11/2024 18.30, Pierrick Bouvier wrote:
On 11/6/24 09:26, Peter Maydell wrote:
On Wed, 6 Nov 2024 at 17:21, Pierrick Bouvier
<pierrick.bouv...@linaro.org> wrote:
I noticed by --enable-debug in configure is a combination of enabling
checks (enable-debug-tcg + graph + mutex), and deactivating optimizations.
Would it be worth keeping the optimizations and runtime checks instead?
This way, there would be no more "timeout" issue.
I'm not sure which added value we get from O0, except for debugging
locally QEMU.
"Debugging locally QEMU" is exactly what --enable-debug is intended for...
Yes...
but it seems like we take it for "enable debug checks" in CI as well and it
impacts runtime, because optimizations are deactivated. I think I've not
been the only one confused about this.
So my point is that we should maybe differentiate the two use cases at
configure level.
--enable-debug and
--enable-runtime-checks (or something more explicit)
Would that really help? I guess people still want to be able to run "make
check" when they compiled with --enable-debug, so we still need to be
prepared to run the checks with a slow QEMU.
Makes sense, even though it seems to indicate we have a wrong default
semantic here.
But I wonder whether we could maybe use -Og instead of -O0 nowadays?
It would not hurt, but I'm not sure it's enough to avoid hitting those
timeout/perf difference issues.
Thomas
