I have now seen the "PC not saved" misbehavior when I attempt to
step OVER the JIT-compiled function.

I am working on your reproducer, but I don't have high hopes. s390x boxes are in VERY short supply, and reservations are seldom "permitted" for more than a day. [Every time I try to keep a s390x box for more than a day, I get emails from others wanting access to it.]

Was there a question in here somewhere? Clearing NEEDINFO.

I have reproduced borrowing the reporter's beaker machine.

Created attachment 1698869 [details]
mesa-meson.sh -- script to do what rhpkg does to build Mesa

Attached is mesa-meson.sh, which is a script I developed
to do what rhpkg local does to build Mesa on non-X86
architectures.

First, you will need a Mesa repo:

# git clone https://gitlab.freedesktop.org/mesa/mesa

Then you need to get to the correct version of Mesa:

# cd mesa
# git checkout mesa-20.1.1

Then you need to build and install Mesa:

# mesa-meson.sh debug install

(This actually does a meson step, a ninja step, and a ninja-install step.)

If you happen to make any modifications to Mesa code, you should
be able to rebuild and reinstall by doing this:

# mesa-meson.sh ninja install

If, for some reason, you want to start over with a clean slate:

# mesa-meson.sh clean debug install

Running the 'tri' demo program in the Mesa demo tree that you cloned
and built earlier:

First, cd to .../demos/src/trivial, and make sure your DISPLAY
environment points to the display you want, e.g.

# export DISPLAY=:1

to display to your VNC server.

Run 'tri' as described above.

Just some notes about this bug while I was investigating (to archive).

To setup:

On s390x box:

dnf install -y mesa-* tigervnc-server metacity xterm
dnf builddep -y mesa-demos
pushd /usr/bin ; ln -s metacity twm ; popd
git clone https://gitlab.freedesktop.org/mesa/demos.git;
cd demos
./autogen.sh
make -j2 CFLAGS="-g -O0"
vncpasswd # enter "redhat"
echo ":1=root" >> /etc/tigervnc/vncserver.users
echo "session=gnome" >> /etc/tigervnc/vncserver-config-defaults
firewall-cmd --permanent --zone=public --add-port=5950/tcp
firewall-cmd --reload
/usr/bin/Xvnc :1 -desktop `hostname`:1 -fp catalogue:/etc/X11/fontpath.d -pn -rfbauth /root/.vnc/passwd -rfbport 5901 -rfbwait 30000 -noreset >& /dev/null &
twm &
xterm &

Locally:

vncviewer BEAKER_MACHINE:1
# enter above vncpasswd into dialog ("redhat")

# Follow gdb install/setup and build gdb

Simple reproducer:

./gdb --data-directory data-directory -nx -iex "set height 0" ../../demos/src/trivial/tri -ex "set breakpoint pending on" -ex "b llvm_pipeline_generic" -ex r -ex "until 617" -ex "disp/i \$pc" -ex "stepi 20" -ex "printf \"stepi here\n\""


After looking at this bug, it is clear that there is something not quite right about the inline frame sniffer.

That calls (eventually) frame_unwind_pc which throws an exception ("PC not saved"). That *surely* must be caught
somewhere, but it is not. Since it is unhandled, it goes through the generic error() handler which longjmps, prints
the exception string, and prints a prompt, skipping displays.

A quick hack around this is to catch OPTIMIZED_OUT_ERROR. I've used the following patch successfully, and while I
know it is not correct, it does cause gdb to behave better:

--- frame.c	2020-06-26 15:05:26.214596623 -0400
+++ frame.c.save	2020-06-26 15:05:16.914596623 -0400
@@ -2125,9 +2125,11 @@
     }
   catch (const gdb_exception_error &ex)
     {
-      if (ex.error == MEMORY_ERROR)
+      if (ex.error == MEMORY_ERROR || ex.error == OPTIMIZED_OUT_ERROR)
 	{
-	  this_frame->stop_reason = UNWIND_MEMORY_ERROR;
+	  this_frame->stop_reason = (ex.error == MEMORY_ERROR
+				     ? UNWIND_MEMORY_ERROR
+				     : UNWIND_NO_SAVED_PC);
 	  if (ex.message != NULL)
 	    {
 	      char *stop_string;

Adding devel score.

I will investigate the terminal problems for 8.4.

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.