public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug gdb/19675] GDB doesn't set PC correctly with displaced stepping over clone syscall
Date: Mon, 13 Nov 2023 14:25:44 +0000	[thread overview]
Message-ID: <bug-19675-4717-XDrO0Y09QJ@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-19675-4717@http.sourceware.org/bugzilla/>

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

--- Comment #6 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Pedro Alves <palves@sourceware.org>:

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

commit 65c459abebf70bd5a64dcee11d4d7d4a8498465f
Author: Pedro Alves <pedro@palves.net>
Date:   Tue Nov 23 20:35:12 2021 +0000

    Thread options & clone events (core + remote)

    A previous patch taught GDB about a new TARGET_WAITKIND_THREAD_CLONED
    event kind, and made the Linux target report clone events.

    A following patch will teach Linux GDBserver to do the same thing.

    However, for remote debugging, it wouldn't be ideal for GDBserver to
    report every clone event to GDB, when GDB only cares about such events
    in some specific situations.  Reporting clone events all the time
    would be potentially chatty.  We don't enable thread create/exit
    events all the time for the same reason.  Instead we have the
    QThreadEvents packet.  QThreadEvents is target-wide, though.

    This patch makes GDB instead explicitly request that the target
    reports clone events or not, on a per-thread basis.

    In order to be able to do that with GDBserver, we need a new remote
    protocol feature.  Since a following patch will want to enable thread
    exit events on per-thread basis too, the packet introduced here is
    more generic than just for clone events.  It lets you enable/disable a
    set of options at once, modelled on Linux ptrace's PTRACE_SETOPTIONS.

    IOW, this commit introduces a new QThreadOptions packet, that lets you
    specify a set of per-thread event options you want to enable.  The
    packet accepts a list of options/thread-id pairs, similarly to vCont,
    processed left to right, with the options field being a number
    interpreted as a bit mask of options.  The only option defined in this
    commit is GDB_THREAD_OPTION_CLONE (0x1), which ask the remote target
    to report clone events.  Another patch later in the series will
    introduce another option.

    For example, this packet sets option "1" (clone events) on thread
    p1000.2345:

      QThreadOptions;1:p1000.2345

    and this clears options for all threads of process 1000, and then sets
    option "1" (clone events) on thread p1000.2345:

      QThreadOptions;0:p1000.-1;1:p1000.2345

    This clears options of all threads of all processes:

      QThreadOptions;0

    The target reports the set of supported options by including
    "QThreadOptions=<supported options>" in its qSupported response.

    infrun is then tweaked to enable GDB_THREAD_OPTION_CLONE when stepping
    over a breakpoint.

    Unlike PTRACE_SETOPTIONS, fork/vfork/clone children do NOT inherit
    their parent's thread options.  This is so that GDB can send e.g.,
    "QThreadOptions;0;1:TID" without worrying about threads it doesn't
    know about yet.

    Documentation for this new remote protocol feature is included in a
    documentation patch later in the series.

    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19675
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27830
    Reviewed-By: Andrew Burgess <aburgess@redhat.com>
    Change-Id: Ie41e5093b2573f14cf6ac41b0b5804eba75be37e

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

  parent reply	other threads:[~2023-11-13 14:25 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-19675-4717@http.sourceware.org/bugzilla/>
2021-08-05  9:54 ` cvs-commit at gcc dot gnu.org
2021-10-20 15:32 ` vries at gcc dot gnu.org
2022-06-21 11:25 ` pedro at palves dot net
2023-11-13 14:25 ` cvs-commit at gcc dot gnu.org
2023-11-13 14:25 ` cvs-commit at gcc dot gnu.org
2023-11-13 14:25 ` cvs-commit at gcc dot gnu.org [this message]
2023-11-13 14:25 ` cvs-commit at gcc dot gnu.org
2023-11-13 14:25 ` cvs-commit at gcc dot gnu.org
2023-11-13 14:26 ` cvs-commit at gcc dot gnu.org
2023-11-13 15:01 ` pedro at palves dot net

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=bug-19675-4717-XDrO0Y09QJ@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=gdb-prs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).