From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by sourceware.org (Postfix) with ESMTPS id 666F439B9C0B for ; Thu, 19 Aug 2021 18:48:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 666F439B9C0B Received: by mail-pj1-x1030.google.com with SMTP id oc2-20020a17090b1c0200b00179e56772d6so2113591pjb.4 for ; Thu, 19 Aug 2021 11:48:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+k5kZ+y8jRWtjhx3Ul7tC9f/fHe7cj4ZFsb13iYlP98=; b=LG1rolYK+0lRcv3DghBduNGIwNlVofyN2dlhcNagxcQ3A3KL8FeUDWFK4jLf92gDF+ +7pIobb+flffY+l8Hlc2HFd9cS+ahufx0qMVLvxJu9qxzgz3XFk0ZwAbrsXXbqm5NE0P PQHXyLCEpPdplE55noGU+BM+TM3bOxbT2eoS8O1wmvNQ3p5xmSH+FVbumc2dNKKUWgMF qI5nsnqW7GzNSvzrCJ3DQzXk2+wRNvhQEZrkRcx9t77KCVHF/mDPX3gLjGEYn2SJdpMX CXSCSvPqPUOR2sotRmD7iHp1Bz0api9b0yZspQWARBpljyOsl6KXdNxo7Ptw7hNBOwbi j9zw== X-Gm-Message-State: AOAM531wZqlddhNuvARE3pkzNilCZkZVOoh5f6MYJU1uRJ7SG2swfeRD dIcAPOC0D8PFnD1Nd2PNSjH2/moWDtSrtg== X-Google-Smtp-Source: ABdhPJxq/dsbAhmorF1lAAFTUuxVnSVRpGnc4q2sEyz797IFs+6ndyd6fqm8+7Eq9adZFCmWXfjL6g== X-Received: by 2002:a17:90a:2845:: with SMTP id p5mr183311pjf.96.1629398936449; Thu, 19 Aug 2021 11:48:56 -0700 (PDT) Received: from ?IPv6:2804:7f0:4841:25bc:7844:a25:b322:60fa? ([2804:7f0:4841:25bc:7844:a25:b322:60fa]) by smtp.gmail.com with ESMTPSA id c11sm3919829pji.24.2021.08.19.11.48.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Aug 2021 11:48:56 -0700 (PDT) Subject: Re: [PATCH] Fix displaced stepping watchpoint check order To: Simon Marchi , gdb-patches@sourceware.org References: <20210608154230.354202-1-luis.machado@linaro.org> <9c697f35-1059-5ea8-83c3-ea75fcc95b32@polymtl.ca> <0ef1ceef-f6b4-7310-bec0-d54d4b646fea@linaro.org> <18bc6e10-91e5-15c9-0455-30004d82b7c8@polymtl.ca> <67e5fcec-2a29-9640-355c-104f5ea03c7a@linaro.org> <79afff97-c28f-1964-0b6c-c2ea9672e5df@polymtl.ca> From: Luis Machado Message-ID: <1851e56c-19f5-011f-b88c-cd953a046248@linaro.org> Date: Thu, 19 Aug 2021 15:48:53 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <79afff97-c28f-1964-0b6c-c2ea9672e5df@polymtl.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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: Thu, 19 Aug 2021 18:49:07 -0000 On 8/19/21 3:23 PM, Simon Marchi wrote: >> Although hardware watchpoints are usually per-thread, I don't think GDB handles it in that level of detail. It seems to mostly ignore insertion of hardware watchpoints if we're trying to step over a PC that caused a hardware watchpoint trigger. >> >> See, for example, breakpoint.c:should_be_inserted >> >> /* Don't insert watchpoints if we're trying to step past the >> instruction that triggered one. */ >> if ((bl->loc_type == bp_loc_hardware_watchpoint) >> && stepping_past_nonsteppable_watchpoint ()) >> { >> infrun_debug_printf ("stepping past non-steppable watchpoint. " >> "skipping watchpoint at %s:%d\n", >> paddress (bl->gdbarch, bl->address), bl->length); >> return 0; >> } >> >> From what I recall, GDB replicates the hardware watchpoints to all threads, so disabling all hardware watchpoints for all threads (actually not inserting them) makes sense. GDB doesn't try to add thread-specific hardware watchpoints at the moment. >> >> Having per-thread hardware watchpoints might be desirable in some cases, but it may complicate the user interaction a bit. >> >> I haven't investigated if GDB, during a step-over operation, keeps threads running with hardware watchpoints disabled. If it doesn't handle it correctly, we may miss hardware watchpoints hits, unless GDB serializes the step-overs. > > That's where I was going too. Just imagine in non-stop, you have many > threads running, one hits the watchpoint. You then want to resume that > thread, that requires stepping over the watchpoint while other threads > are running. If the watchpoint was really removed for all running > threads, a running thread could miss it. > > But watchpoints aren't like memory breakpoints, they are usually set > using debug register, which are per-thread, so you can't really remove a > watchpoint from a running thread... that's why I was thinking that maybe > the watchpoint was only removed for the thread stepping over the > watchpoint. But maybe not. That's true. It might be the case that GDB is only removing the hardware watchpoint from the stopped thread. And it does so through context, by having selected a particular thread explicitly at some point. As opposed to commanding the inferior to remove hardware watchpoints from all threads. I'm pretty sure we'd get a ptrace error otherwise. > >> "Presently GDB can only step over one breakpoint at any given time." > > There can be only one in-line step at a time. But there can be multiple > displaced steps at a time (since somewhat recently). There can't be an > in-line step at the same time as some displaced steps. While an in-line > step is in progress, it is guaranteed that there are no other running > threads. > > Reading keep_going_pass_signal, I might understand that watchpoints are > always stepped using the in-line mechanism, while all other threads are > stopped. I would have to try it. That makes sense. > > Simon >