Message ID | 20221203211338.2264994-1-pedro@palves.net |
---|---|
Headers |
Return-Path: <gdb-patches-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B3B98385B187 for <patchwork@sourceware.org>; Sat, 3 Dec 2022 21:13:55 +0000 (GMT) X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) by sourceware.org (Postfix) with ESMTPS id 049983858D20 for <gdb-patches@sourceware.org>; Sat, 3 Dec 2022 21:13:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 049983858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f41.google.com with SMTP id o5so13099462wrm.1 for <gdb-patches@sourceware.org>; Sat, 03 Dec 2022 13:13:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=di/in3c4NMRbwgzLb0TlpxVk++l3JkVdik8Vymy6tfE=; b=c1VE7+F1WBOte3AvHpadBMMRs1ygGPG0GudcztWd23i4yF6Q9NbjMDGzvKc/v/pEX6 VZrRC068BxSfna4OyMoV99aa0+98NuhTpMwvBDczrKK82zoUOz0AxHvWmlLXzGiLTId1 MSC68v1w/6Pr3iZEVxXJ0tyAt3fyGjJYG5QKrYBJ4s6xYkWABG7NXVTjddzk9w+xWaZ6 7ADmPCCOnpi2REZRa0HZQsAL4HtTmDF80KLrIDVQTxexu1qnMZAdaDXWvtBQO+KOzyrx L/NHQYAMya2Aj1CULYLQmrajmbqd/hyXaooqL1EHOa5ZE0CSkVdmxG7s4qelIuerGWKY l3gg== X-Gm-Message-State: ANoB5pnkB6bd3MSOp7qbFp3SwDf1xq1icU2ZgzdF7E/7JDVp9rJgnxnS bbWC/NeTNECNRNpBCqzBcBvg22Fh/UK1mw== X-Google-Smtp-Source: AA0mqf5kEFcQ/9cDklLSTBhjAPiCS/7xDYCjF2PeaEgTyqI+FNKZYwy6uPF+mPaGLUCgbNP+J3F6Pw== X-Received: by 2002:a5d:56d2:0:b0:236:cdf8:1e3f with SMTP id m18-20020a5d56d2000000b00236cdf81e3fmr38653303wrw.80.1670102020741; Sat, 03 Dec 2022 13:13:40 -0800 (PST) Received: from localhost ([2001:8a0:f912:6700:afd9:8b6d:223f:6170]) by smtp.gmail.com with ESMTPSA id l28-20020a05600c1d1c00b003c6b7f5567csm21001672wms.0.2022.12.03.13.13.40 for <gdb-patches@sourceware.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 03 Dec 2022 13:13:40 -0800 (PST) From: Pedro Alves <pedro@palves.net> To: gdb-patches@sourceware.org Subject: [PATCH 0/6] Eliminate infrun_thread_thread_exit observer Date: Sat, 3 Dec 2022 21:13:32 +0000 Message-Id: <20221203211338.2264994-1-pedro@palves.net> X-Mailer: git-send-email 2.36.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list <gdb-patches.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=subscribe> Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org Sender: "Gdb-patches" <gdb-patches-bounces+patchwork=sourceware.org@sourceware.org> |
Series |
Eliminate infrun_thread_thread_exit observer
|
|
Message
Pedro Alves
Dec. 3, 2022, 9:13 p.m. UTC
This series started out as me realizing that I had one change in the pending step-over-thread-exit series that was in conflict with infrun_thread_thread_exit. infrun_thread_thread_exit wants to clear the last target waitstatus when that status is for the thread that exited, while I'll need to preserve the thread exit waitstatus for normal stop. In the step-over-thread-exit series, I was calling set_last_target_status again when handling a TARGET_WAITKING_THREAD_EXIT, and that was undoing the clear that infrun_thread_thread_exit does. So I looked at eliminating infrun_thread_thread_exit, see if we could make whatever is relying on it no longer rely on it. The end result is this thread. It ends up fixing some bugs and improving GDB behavior such that I think it stands on its own, even without the last patch, the one that finally eliminates infrun_thread_thread_exit. I kept the thread title about infrun_thread_thread_exit because that's my end goal, but I could as well remove the last patch and call this thread "improve 'info program' and 'follow-fork'". Tested on x86-64 GNU/Linux, native and extended-gdbserver. Pedro Alves (6): Tweak "Using the running image of ..." output Convert previous_inferior_ptid to strong reference to thread_info Improve "info program" Make follow_fork not rely on get_last_target_status all-stop "follow-fork parent" and selecting another thread Remove infrun_thread_thread_exit observer gdb/inf-ptrace.c | 2 +- gdb/infcmd.c | 84 +++++-- gdb/infrun.c | 214 +++++++++++++----- gdb/infrun.h | 7 + gdb/nto-procfs.c | 2 +- gdb/procfs.c | 2 +- gdb/target.c | 5 + gdb/testsuite/gdb.base/catch-follow-exec.exp | 17 +- gdb/testsuite/gdb.base/foll-fork.exp | 36 ++- gdb/testsuite/gdb.base/info-program.c | 66 ++++++ gdb/testsuite/gdb.base/info-program.exp | 131 +++++++++-- .../gdb.threads/foll-fork-other-thread.c | 84 +++++++ .../gdb.threads/foll-fork-other-thread.exp | 172 ++++++++++++++ gdb/windows-nat.c | 2 +- 14 files changed, 712 insertions(+), 112 deletions(-) create mode 100644 gdb/testsuite/gdb.base/info-program.c create mode 100644 gdb/testsuite/gdb.threads/foll-fork-other-thread.c create mode 100644 gdb/testsuite/gdb.threads/foll-fork-other-thread.exp base-commit: fb699bafb5f23c2fd43d7f20495171b16903b20f
Comments
Hi! On 2022-12-03 9:13 p.m., Pedro Alves wrote: > This series started out as me realizing that I had one change in the > pending step-over-thread-exit series that was in conflict with > infrun_thread_thread_exit. infrun_thread_thread_exit wants to clear > the last target waitstatus when that status is for the thread that > exited, while I'll need to preserve the thread exit waitstatus for > normal stop. In the step-over-thread-exit series, I was calling > set_last_target_status again when handling a > TARGET_WAITKING_THREAD_EXIT, and that was undoing the clear that > infrun_thread_thread_exit does. > > So I looked at eliminating infrun_thread_thread_exit, see if we could > make whatever is relying on it no longer rely on it. > > The end result is this thread. It ends up fixing some bugs and > improving GDB behavior such that I think it stands on its own, even > without the last patch, the one that finally eliminates > infrun_thread_thread_exit. I kept the thread title about > infrun_thread_thread_exit because that's my end goal, but I could as > well remove the last patch and call this thread "improve 'info > program' and 'follow-fork'". > > Tested on x86-64 GNU/Linux, native and extended-gdbserver. > > Pedro Alves (6): > Tweak "Using the running image of ..." output > Convert previous_inferior_ptid to strong reference to thread_info > Improve "info program" > Make follow_fork not rely on get_last_target_status > all-stop "follow-fork parent" and selecting another thread > Remove infrun_thread_thread_exit observer FYI, I'm putting this in.