We are skipping a lot of tests when optimizations are enabled (which essentially means: compiled without --with-pydebug). This seems overly aggressive since most Python users are using the gdb bindings with a non-debug build.

I think we should have tests for py-bt, py-up, printing globals, etc. that run on a non-debug build.

Sadly, python-gdb fails to get required data for some commands, so python-gdb doesn't work fully on optimized builds.

You're being vague, can you say which optimized builds and which data? As I mentioned, builds that actual users use are almost always compiled without --with-pydebug. That includes, say, the default RedHat python RPMs or the Debian DEBs that ship with those operating systems.

It's not enough for us to run those tests only for --with-pydebug, as shown by bpo-30983, which wasn't discovered sooner because it only affects shared non-debug builds.

I don't think it's a surprise that reconstructing high-level program information from a debugger works less well on optimized builds. Perhaps Dave Malcolm has more precise information about what is supposed to to work and what is not.

The problem is that there are so many variables:

• which version of which compiler
• optimization flags
• which version of gdb
• which CPU architecture
  etc (and the compiler and/or gdb could be carrying patches from downstream distributors...)

All of these can affect the debugging experience; as soon as optimizations are turned on it's very hard to predict exactly how well we can capture the frame information in the debugger.

Hence it makes sense to skip these tests for optimized builds, to avoid creating noise in the buildbots.

Downstream distributions might want to re-enable the tests, if they have sufficient control over the compiler and debugger versions that are in use, I guess.

Or maybe there's a way to express some of the above sanely? Not sure.

Hope this is constructive.

I guess it's wontfix then. Sad, since that leaves us partially blind to regressions like bpo-30983.