[Bug gdb/16678] record problem with recursion

["cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Bruno Larsen <blarsen@sourceware.org>:

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

commit 49d7cd733a7f1b87aa1d40318b3d7c2b65aca5ac
Author: Bruno Larsen <blarsen@redhat.com>
Date:   Fri Aug 19 15:11:28 2022 +0200

    Change calculation of frame_id by amd64 epilogue unwinder

    When GDB is stopped at a ret instruction and no debug information is
    available for unwinding, GDB defaults to the amd64 epilogue unwinder, to
    be able to generate a decent backtrace. However, when calculating the
    frame id, the epilogue unwinder generates information as if the return
    instruction was the whole frame.

    This was an issue especially when attempting to reverse debug, as GDB
    would place a step_resume_breakpoint from the epilogue of a function if
    we were to attempt to skip that function, and this breakpoint should
    ideally have the current function's frame_id to avoid other problems
    such as PR record/16678.

    This commit changes the frame_id calculation for the amd64 epilogue,
    so that it is always the same as the dwarf2 unwinder's frame_id.

    It also adds a test to confirm that the frame_id will be the same,
    regardless of using the epilogue unwinder or not, thanks to Andrew
    Burgess.

    Co-Authored-By: Andrew Burgess <aburgess@redhat.com>

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