From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) by sourceware.org (Postfix) with ESMTPS id 18B623857404 for ; Mon, 21 Mar 2022 17:29:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 18B623857404 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-wm1-f54.google.com with SMTP id r7so9005034wmq.2 for ; Mon, 21 Mar 2022 10:29:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:from:to:references:in-reply-to :content-transfer-encoding; bh=YtBm5Fjm8FtSFKMcoSI06DV72yYfu45lBtMIy20KlXU=; b=V9G8gVRRTDGVdZfobUIU1wgX7xdwspnh7XQcMmCp1dDVntYCNhvR6wTTzynjXQQUtX Y5ykkI2l2a9F+ed+QG5hKfG802CUqOho3lznISyk14gMyv2DW5r1YAOfXGRdWACHDwiU zpbPJrmNsg37hMBGneVMYk5s04c2OAdCeNDrZAn5A3YkgmNan8p0CySJ3fUrip9FH8Ru hYuEugguAzxU9tnVxzSnLBLPdF03cIXWHAEYKjBtK+vHNHt4cNpnSu4jEK89/fEu5SR/ g3QxAekFCkLr1uXEl+0yHh4l7cb1w+4sSt7UbcHTMqPq/m8wKdwLeuRcu147tm/zkLOs EmLQ== X-Gm-Message-State: AOAM530wH0wOXRk2nYDSqwGWoU04CJiQeccnndH2ZD3ORe4t3cgrbx+U FwepnuiPCJfTAKuH0rj2tu1HUCUPYYY= X-Google-Smtp-Source: ABdhPJyvQWUyUoe/dMlP/rqSqTOL4E8x/7i48/JXuaD+WQtoAtcQFBZ3hWunICzhOpQkm883JR8Amg== X-Received: by 2002:a7b:cd82:0:b0:389:77ef:66d7 with SMTP id y2-20020a7bcd82000000b0038977ef66d7mr113958wmj.171.1647883741424; Mon, 21 Mar 2022 10:29:01 -0700 (PDT) Received: from ?IPV6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id c24-20020a7bc018000000b0038a18068cf5sm101810wmb.15.2022.03.21.10.29.00 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Mar 2022 10:29:00 -0700 (PDT) Message-ID: <0e99645e-f435-7d6e-fd6e-a474cdb151e4@palves.net> Date: Mon, 21 Mar 2022 17:28:59 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH] Watchpoint followed by catchpoint misreports watchpoint (PR gdb/28621) Content-Language: en-US From: Pedro Alves To: gdb-patches@sourceware.org References: <20220307165600.906162-1-pedro@palves.net> In-Reply-To: <20220307165600.906162-1-pedro@palves.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2022 17:29:04 -0000 On 2022-03-07 16:56, Pedro Alves wrote: > If GDB reports a watchpoint hit, and then the next event is not > TARGET_WAITKIND_STOPPED, but instead some event for which there's a > catchpoint, such that GDB calls bpstat_stop_status, GDB mistakenly > thinks the watchpoint triggered. Vis, using foll-fork.c: > > (gdb) awatch v > Hardware access (read/write) watchpoint 2: v > (gdb) catch fork > Catchpoint 3 (fork) > (gdb) c > Continuing. > > Hardware access (read/write) watchpoint 2: v > > Old value = 0 > New value = 5 > main () at gdb.base/foll-fork.c:16 > 16 pid = fork (); > (gdb) > Continuing. > > Hardware access (read/write) watchpoint 2: v <<<< > <<<< these lines are spurious > Value = 5 <<<< > > Catchpoint 3 (forked process 1712369), arch_fork (ctid=0x7ffff7fa4810) at arch-fork.h:49 > 49 arch-fork.h: No such file or directory. > (gdb) > > The problem is that when we handle the fork event, nothing called > watchpoints_triggered before calling bpstat_stop_status. Thus, each > watchpoint's watchpoint_triggered field was still set to > watch_triggered_yes from the previous (real) watchpoint stop. > watchpoint_triggered is only current called in the handle_signal_stop > path, when handling TARGET_WAITKIND_STOPPED. > > This fixes it by adding watchpoint_triggered calls in the other events > paths that call bpstat_stop_status. But instead of adding them > explicitly, it adds a new function bpstat_stop_status_nowatch that > wraps bpstat_stop_status and calls watchpoint_triggered, and then > replaces most calls to bpstat_stop_status with calls to > bpstat_stop_status_nowatch. > > This required constifying watchpoints_triggered. > > New test included, which fails without the fix. > > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28621 > > Change-Id: I282b38c2eee428d25319af3bc842f9feafed461c I've merged this to master. Pedro Alvse