René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Have debug builds support gdb extension by default","articleBody":"# Feature or enhancement\n\n### Proposal:\n\nWhile investigating https://github.com/python/cpython/pull/91961 and specifically https://github.com/python/cpython/pull/108999, we noticed that test_gdb fails (or used to fail) very frequently on buildbots, or some tests are skipped.\n\nMost of the times, the skips/failures are on clang builds, which often don't have the necessary information to inspect Python frames. Compiling with the right optimization options (or, rather, without optimization) allows gdb to inspect Python frames on clang builds just fine (or almost).\n\nI would like to propose to set an expectation that **a `--with-pydebug` build should be debuggable with the Python extension to gdb in most configurations *by default*** (that is, without additional compiler flags or shenanigans), and attempt to guarantee this as much as possible. This should be possible on basically all platforms where gcc or clang are used, and it's already basically certain with gcc.\n\n---\n\nSome details of what the proposal entails as far as I understand:\n\n1) Easy one: don't [imply `-Og` for debug builds](https://github.com/python/cpython/blob/60b8341d07649194aa73108369a1e04ed1848794/configure.ac#L2032-L2036) on clang. `-Og` on clang is the same as `-O1` (but it could change in the future) and performs certain (which?) optimization passes that don't work well with debug inspection. `-fno-inline` is not sufficient to prevent that, although some other option might be. Otherwise, defaulting to `-O0` will work, but might take longer to compile and generate very inefficient code. If this is acceptable, it could be all there is to it :)\n\n2) During my testing, I saw one test failed/skipped (`test_print_after_up`) that had one more python frame than expected, i.e. it worked with one more `py-up`. I haven't investigated why, so it could be a legitimate case that tests should consider, or a bug, or just an artifact given by different compile options (maybe gcc -Og inlines something and clang -O0 doesn't). In any case, skipping might mask a potential issue that could be fixable. Which brings to point 3.\n\n3) How to test? test_gdb skips in many cases that are indistinguishable from failures. Knowing that you cannot read a Python frame could mean that the build doesn't include debug information, but it can also mean that the `libpython.py` extension is making incorrect assumptions. IMO it would be good to have some setups where tests are expected to pass (and ensure buildbots are covering those) and fewer or no tests are allowed to skip. This way test_gdb itself can be used to cover not only that the gdb extension works, but also that (that specific build of) CPython is debuggable. It could be an explicit flag like \"this build should be debuggable\", exposed via `sysconfig`[^1].\n\n[^1]: test_gdb checks sysconfig for compiler flags to infer whether the build is optimized. This is on a similar track as what I'm suggesting in point 3, but the current behavior is to use this information to skip tests early. Even if the build is not optimized, tests can be skipped anyway, and failures are masked. Besides, the check looks for `-Og` which works for gcc but not for clang.\n\n---\n\nEven if the proposal to offer some kind of debuggability-by-default with `--with-pydebug` is rejected, maybe some work can be done to improve the clang situation.\n\n### Has this already been discussed elsewhere?\n\nThis is a minor feature, which does not need previous discussion elsewhere\n\n### Links to previous discussion of this feature:\n\n_No response_","author":{"url":"https://github.com/sorcio","@type":"Person","name":"sorcio"},"datePublished":"2023-09-11T14:27:32.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":3},"url":"https://github.com/109270/cpython/issues/109270"}