public inbox for
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot" <>
Subject: [Bug gdb/30872] Assertion `buffer.copy_insn_closure.get () != nullptr' failed
Date: Mon, 16 Oct 2023 10:57:15 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

--- Comment #13 from cvs-commit at gcc dot <cvs-commit at gcc dot> ---
The master branch has been updated by Luis Machado <>:;h=5d4a870e05ac45e3f5a301c672a4079995b5db7a

commit 5d4a870e05ac45e3f5a301c672a4079995b5db7a
Author: Luis Machado <>
Date:   Thu Sep 28 11:08:29 2023 +0100

    Only allow closure lookup by address if there are threads

    Since commit 1e5ccb9c5ff4fd8ade4a8694676f99f4abf2d679, we have an assertion
    displaced_step_buffers::copy_insn_closure_by_addr that makes sure a closure
    is available whenever we have a match between the provided address argument
    the buffer address.

    That is fine, but the report in PR30872 shows this assertion triggering
    it really shouldn't. After some investigation, here's what I found out.

    The 32-bit Arm architecture is the only one that calls
    gdbarch_displaced_step_copy_insn_closure_by_addr directly, and that's
    32-bit Arm needs to figure out the thumb state of the original instruction
    that we displaced-stepped through the displaced-step buffer.

    Before the assertion was put in place by commit
    1e5ccb9c5ff4fd8ade4a8694676f99f4abf2d679, there was the possibility of
    getting nullptr back, which meant we were not doing a displaced-stepping

    Now, with the assertion in place, this is running into issues.

    It looks like displaced_step_buffers::copy_insn_closure_by_addr is
    being used to return a couple different answers depending on the
    state we're in:

    1 - If we are actively displaced-stepping, then copy_insn_closure_by_addr
    is supposed to return a valid closure for us, so we can determine the
    thumb mode.

    2 - If we are not actively displaced-stepping, then
    should return nullptr to signal that there isn't any displaced-step buffers
    in use, because we don't have a valid closure (but we should always have

    Since the displaced-step buffers are always allocated, but not always used,
    that means the buffers will always contain data. In particular, the buffer
    addr field cannot be used to determine if the buffer is active or not.

    For instance, we cannot set the buffer addr field to 0x0, as that can be a
    valid PC in some cases.

    My understanding is that the current_thread field should be a good
    to signal that a particular displaced-step buffer is active or not. If it
    nullptr, we have no threads using that buffer to displaced-step. 
    it is an active buffer in use by a particular thread.

    The following fix modifies the
    function so we only attempt to return a closure if the buffer has an
    current_thread and if the buffer address matches the address argument.

    Alternatively, I think we could use a function to answer the question of
    whether we're actively displaced-stepping (so we have an active buffer) or

    I've also added a testcase that exercises the problem. It should reproduce
    reliably on Arm, as that is the only architecture that faces this problem
    at the moment.

    Regression-tested on Ubuntu 20.04. OK?

    Approved-By: Simon Marchi <>

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

  parent reply	other threads:[~2023-10-16 10:57 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-19  9:43 [Bug gdb/30872] New: " zbigniew2011 at gmail dot com
2023-09-19 12:02 ` [Bug gdb/30872] " zbigniew2011 at gmail dot com
2023-09-19 12:29 ` tromey at sourceware dot org
2023-09-19 12:34 ` zbigniew2011 at gmail dot com
2023-09-19 16:02 ` ssbssa at sourceware dot org
2023-09-19 18:00 ` tromey at sourceware dot org
2023-09-19 20:31 ` luis.machado at arm dot com
2023-09-27 11:46 ` luis.machado at arm dot com
2023-09-27 12:39 ` luis.machado at arm dot com
2023-09-27 13:27 ` zbigniew2011 at gmail dot com
2023-09-27 14:07 ` luis.machado at arm dot com
2023-09-28  8:13 ` luis.machado at arm dot com
2023-09-28 10:50 ` sam at gentoo dot org
2023-09-29  8:16 ` luis.machado at arm dot com
2023-10-16 10:57 ` cvs-commit at gcc dot [this message]
2023-10-16 10:59 ` cvs-commit at gcc dot
2023-10-16 11:01 ` luis.machado at arm dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).