"PC not saved" message, no disassembly on attempt to stepi through JIT-compiled code

Description of problem:

When I attempt to single-step into JIT-compiled code on S390x,
my gdb process gets stopped and backgrounded as soon as I execute
the basr instruction that called the JIT-compiled function.
I can fg the process, at which point gdb reports "PC not saved."
If I stepi again, exactly the same thing happens.

Each time I fg the process, I can see the pc incrementing, and
instruction effects (e.g. changes to contents of general registers)
have clearly taken place. The command "disp/i $pc" works as
expected. The "disassemble" command works fine, e.g.
disassemble $pc, $pc+10.

But stepi is broken and essentially unusable.

Gdb from the Developer Tool Set is marginally better, in that
it does not stop and kick me out to the command line, but it
still reports "PC not saved" and otherwise operates as above.

Version-Release number of selected component (if applicable):

gdb 8.2-12.el8
gcc-toolset-10-gdb 9.2-2.el8
kernel 4.18.0-214.el8.s390x

How reproducible:

100%

Steps to Reproduce:
1. Install tigervnc, metacity, and all mesa packages including debuginfo
2. Do NOT install gnome-shell at this time; use metacity as window manager:
3. cd /usr/bin ; ln -s metacity twm
4. Install Mesa demos from https://gitlab.freedesktop.org/mesa/demos and build
5. Start VNC server with display =, e.g., :1
6. Start the window manager if it hasn't already started: twm
7. export DISPLAY=:1
8. Start an X application like xclock or xterm to verify operation of server
and window manager
9. In <mesa demos>/src/trivial, gdb tri
10. set a breakpoint in llvm_pipeline_generic
11. Once you hit that breakpoint, look for a line that looks like this:
clipped = fpme->current_variant->jit_func(&fpme->llvm->jit_context,...
Should be ~line 617.
12. Continue until you hit that breakpoint
13. (gdb) set disassemble-next-line on
14. stepi until you're about to execute the basr instruction to call
the JIT-compiled function;
15. stepi one more time (i.e. execute the basr), bad behavior will occur.

Actual results:

As described above

Expected results:

Execution and disassembly continue seamlessly in the new code.

Additional info: