me> I'm having a hard time debugging some virtual machine code because GDB won't break where it's supposed to.

Here's a quick follow-up. I tried a number of different values of OPT during configuration and compilation, but nothing changed the result. I could never (and still can't) get GDB to break at the line it announces when a breakpoint is set using the TARGET_* labels generated for computed gotos. I also backed away from my dev branch and switched to up-to-date versions of main and 3.10. No difference...

So, I opened a bug against GDB:

https://sourceware.org/bugzilla/show_bug.cgi?id=27907

and ... wait for it ...

The person who responded (Keith Seitz @ RedHat) was unable to reproduce the problem. He encouraged me to build GDB and try again, and with some effort I was able to build an executable (wow, the GDB build process makes building Python look like a piece of cake). Still, the difference between the announced and actual line numbers of the breakpoint remains.

I disabled Python support in GDB by renaming my ~/.gdbinit file which declares

add-auto-load-safe-path /home/skip/src/python/rvm

That had no effect either. I don't have any LD_*_PATH environment variables set. I think I've run out of things to try.

I don't recall anyone here indicating they'd tried to replicate the problem. Could I bother someone to give it a whirl? It's easy. Just run GDB referring to a Python executable with computed gotos enabled and debug symbols included. At the (gdb) prompt, execute:

b ceval.c:_PyEval_EvalFrameDefault:TARGET_LOAD_CONST
run

and compare the line number announced when the breakpoint is set with the line number announced when execution stops. On my main branch (updated yesterday), using

OPT='-O3 -g -Wall'

I get an absolutely bonkers break in the action:

% ~/src/binutils-gdb/gdb/gdb ./pythonild.sh
GNU gdb (GDB) 11.0.50.20210524-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./python...
(gdb) b ceval.c:_PyEval_EvalFrameDefault:TARGET_LOAD_CONST
Breakpoint 1 at 0x5e934: file Python/ceval.c, line 1836.
(gdb) r
Starting program: /home/skip/src/python/rvm/python
warning: the debug information found in "/lib64/ld-2.31.so" does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch).

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, 0x00005555555b2934 in _PyEval_EvalFrameDefault (tstate=<optimized out>, f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:2958
2958             DISPATCH();

LOAD_CONST is, in fact, defined at line ceval.c:1836. Line 2958 is the last line of the implementation of LOAD_NAME, just a few lines away :-/.

If I get more detailed with the configure/compile options I can get the difference down to a few lines, but I've yet to see it work correctly. 

I'm currently offering 

OPT='-g -O0 -Wall' --with-pydebug --with-trace-refs

to the configure script. In most any other program, breaking a few lines ahead of where you wanted would just be an annoyance, but in the Python virtual machine, it makes the breakpoint useless.

Skip