[Bug backtrace/28313] New: [s390] "PC not saved" when debugging without binary

[Bug backtrace/28313] New: [s390] "PC not saved" when debugging without binary

[arnez at linux dot ibm.com]

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

            Bug ID: 28313
           Summary: [s390] "PC not saved" when debugging without binary
           Product: gdb
           Version: unknown
            Status: NEW
          Severity: normal
          Priority: P2
         Component: backtrace
          Assignee: unassigned at sourceware dot org
          Reporter: arnez at linux dot ibm.com
  Target Milestone: ---

Several people have seen a "PC not saved" error when trying to debug programs
without an associated binary on s390x.  One way this can be reproduced is by
attaching to a program whose binary has been deleted:

(gdb) attach 3272749
Attaching to process 3272749
No executable file now.
warning: Could not load vsyscall page because no executable was specified
0x000003fffddcf186 in ?? ()
(gdb) display/i $pc
1: x/i $pc
=> 0x3fffddcf186:       lghi    %r1,-4096
(gdb) si
PC not saved
(gdb) p $pc
$1 = (void (*)()) 0x3fffddcf18a

Note that the "PC not saved" error prevents the printing of the auto-display
expression in this case.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug backtrace/28313] [s390] "PC not saved" when debugging without binary

[ulrich.weigand at de dot ibm.com]

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

ulrich.weigand at de dot ibm.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ulrich.weigand at de dot ibm.com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug backtrace/28313] [s390] "PC not saved" when debugging without binary

[keiths at redhat dot com]

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

Keith Seitz <keiths at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |keiths at redhat dot com

--- Comment #1 from Keith Seitz <keiths at redhat dot com> ---
This was reported by a user to Red Hat's bugzilla instance, too:

https://bugzilla.redhat.com/show_bug.cgi?id=1850710

In that bug, I give a workaround patch to mitigate the issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug backtrace/28313] [s390] "PC not saved" when debugging without binary

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Andrew Burgess <aburgess@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=e58beedf2c8a1e0c78e0f57aeab3934de9416bfc

commit e58beedf2c8a1e0c78e0f57aeab3934de9416bfc
Author: Andrew Burgess <aburgess@redhat.com>
Date:   Tue Jan 23 16:00:59 2024 +0000

    gdb: attach to a process when the executable has been deleted

    Bug PR gdb/28313 describes attaching to a process when the executable
    has been deleted.  The bug is for S390 and describes how a user sees a
    message 'PC not saved'.

    On x86-64 (GNU/Linux) I don't see a 'PC not saved' message, but
    instead I see this:

      (gdb) attach 901877
      Attaching to process 901877
      No executable file now.
      warning: Could not load vsyscall page because no executable was specified
      0x00007fa9d9c121e7 in ?? ()
      (gdb) bt
      #0  0x00007fa9d9c121e7 in ?? ()
      #1  0x00007fa9d9c1211e in ?? ()
      #2  0x0000000000000007 in ?? ()
      #3  0x000000002dc8b18d in ?? ()
      #4  0x0000000000000000 in ?? ()
      (gdb)

    Notice that the addresses in the backtrace don't seem right, quickly
    heading to 0x7 and finally ending at 0x0.

    What's going on, in both the s390 case and the x86-64 case is that the
    architecture's prologue scanner is going wrong and causing the stack
    unwinding to fail.

    The prologue scanner goes wrong because GDB has no unwind information.

    And GDB has no unwind information because, of course, the executable
    has been deleted.

    Notice in the example session above we get this line in the output:

      No executable file now.

    which indicates that GDB failed to find an executable to debug.

    For GNU/Linux when GDB tries to find an executable for a given pid we
    end up calling linux_proc_pid_to_exec_file in gdb/nat/linux-procfs.c.
    Within this function we call `readlink` on /proc/PID/exe to find the
    path of the actual executable.

    If the `readlink` call fails then we already fallback on using
    /proc/PID/exe as the path to the executable to debug.

    However, when the executable has been deleted the `readlink` call
    doesn't fail, but the path that is returned points to a non-existent
    file.

    I propose that we add an `access` call to linux_proc_pid_to_exec_file
    to check that the target file exists and can be read.  If the target
    can't be read then we should fall back to /proc/PID/exe (assuming that
    /proc/PID/exe can be read).

    Now on x86-64 the output looks like this:

      (gdb) attach 901877
      Attaching to process 901877
      Reading symbols from /proc/901877/exe...
      Reading symbols from /lib64/libc.so.6...
      (No debugging symbols found in /lib64/libc.so.6)
      Reading symbols from /lib64/ld-linux-x86-64.so.2...
      (No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
      0x00007fa9d9c121e7 in nanosleep () from /lib64/libc.so.6
      (gdb) bt
      #0  0x00007fa9d9c121e7 in nanosleep () from /lib64/libc.so.6
      #1  0x00007fa9d9c1211e in sleep () from /lib64/libc.so.6
      #2  0x000000000040117e in spin_forever () at attach-test.c:17
      #3  0x0000000000401198 in main () at attach-test.c:24
      (gdb)

    which is much better.

    I've also tagged the bug PR gdb/29782 which concerns the test
    gdb.server/connect-with-no-symbol-file.exp.  After making this change,
    when running gdb.server/connect-with-no-symbol-file.exp GDB would now
    pick up the /proc/PID/exe file as the executable in some cases.

    As GDB is not restarted for the multiple iterations of this test
    GDB (or rather BFD) would given a warning/error like:

      (gdb) PASS: gdb.server/connect-with-no-symbol-file.exp: sysroot=target::
action=permission: setup: disconnect
      set sysroot target:
      BFD: reopening /proc/3283001/exe: No such file or directory
      (gdb) FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=target::
action=permission: setup: adjust sysroot

    What's happening is that an executable found for an earlier iteration
    of the test is still registered for the inferior when we are setting
    up for a second iteration of the test.  When the sysroot changes, if
    there's an executable registered GDB tries to reopen it, but in this
    case the file has disappeared (the previous inferior has exited by
    this point).

    I did think about maybe, when the executable is /proc/PID/exe, we
    should auto-delete the file from the inferior.  But in the end I
    thought this was a bad idea.  Not only would this require a lot of
    special code in GDB just to support this edge case: we'd need to track
    if the exe file name came from /proc and should be auto-deleted, or
    we'd need target specific code to check if a path should be
    auto-deleted.....

    ... in addition, we'd still want to warn the user when we auto-deleted
    the file from the inferior, otherwise they might be surprised to find
    their inferior suddenly has no executable attached, so we wouldn't
    actually reduce the number of warnings the user sees.

    So in the end I figured that the best solution is to just update the
    test to avoid the warning.  This is easily done by manually removing
    the executable from the inferior once each iteration of the test has
    completed.

    Now, in bug PR gdb/29782 GDB is clearly managing to pick up an
    executable from the NFS cache somehow.  I guess what's happening is
    that when the original file is deleted /proc/PID/exe is actually
    pointing to a file in the NFS cache which is only deleted at some
    later point, and so when GDB starts up we do manage to associate a
    file with the inferior, this results in the same message being emitted
    from BFD as I was seeing.  The fix included in this commit should also
    fix that bug.

    One final note:  On x86-64 GNU/Linux, the
    gdb.server/connect-with-no-symbol-file.exp test will produce 2 core
    files.  This is due to a bug in gdbserver that is nothing to do with
    this test.  These core files are created before and after this
    commit.  I am working on a fix for the gdbserver issue, but will post
    that separately.

    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28313
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29782

    Approved-By: Tom Tromey <tom@tromey.com>

-- 
You are receiving this mail because:
You are on the CC list for the bug.