From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69491 invoked by alias); 26 Nov 2019 16:58:56 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 69483 invoked by uid 89); 26 Nov 2019 16:58:56 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 spammy=happening X-HELO: mx1.osci.io Received: from polly.osci.io (HELO mx1.osci.io) (8.43.85.229) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 26 Nov 2019 16:58:55 +0000 Received: by mx1.osci.io (Postfix, from userid 994) id 8AC83203AE; Tue, 26 Nov 2019 11:58:53 -0500 (EST) Received: from gnutoolchain-gerrit.osci.io (gnutoolchain-gerrit.osci.io [IPv6:2620:52:3:1:5054:ff:fe06:16ca]) by mx1.osci.io (Postfix) with ESMTP id 3DB102030C; Tue, 26 Nov 2019 11:58:52 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by gnutoolchain-gerrit.osci.io (Postfix) with ESMTP id 1BBC320AF6; Tue, 26 Nov 2019 11:58:52 -0500 (EST) X-Gerrit-PatchSet: 2 Date: Tue, 26 Nov 2019 16:58:00 -0000 From: "Simon Marchi (Code Review)" To: Mihails Strasuns , gdb-patches@sourceware.org Auto-Submitted: auto-generated X-Gerrit-MessageType: comment Subject: [review v2] jit: remove bp locations when unregistering jit code X-Gerrit-Change-Id: Id9133540d67fa0c4619ac88324b0349b89e4b2b1 X-Gerrit-Change-Number: 704 X-Gerrit-ChangeURL: X-Gerrit-Commit: 232c479ef55b074173b1547b2072916bba6904c2 In-Reply-To: References: X-Gerrit-Comment-Date: Tue, 26 Nov 2019 11:58:51 -0500 Reply-To: gnutoolchain-gerrit@osci.io MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Disposition: inline User-Agent: Gerrit/3.0.3-79-g83ff7f88f1 Content-Type: text/plain; charset=UTF-8 Message-Id: <20191126165852.1BBC320AF6@gnutoolchain-gerrit.osci.io> X-SW-Source: 2019-11/txt/msg00871.txt.bz2 Simon Marchi has posted comments on this change. Change URL: https://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/704 ...................................................................... Patch Set 2: > Patch Set 1: > > > Patch Set 1: > > > > Just trying to understand the problem better. From what I understand, when the breakpoint locations must be updated following a code change event (e.g. solib getting loaded or unloaded), we call breakpoint_re_set, which goes through all breakpoint locations and sees if they must be updated. Have you tryied calling this from jit_unregister_code? > > Have tried it now, just in case - it doesn't work. As far as I understand the problem here is that from the gdb PoV breakpoint locations with the same address are the same and `locations_are_equal (existing_locations, b->loc)` condition is true. Because of that updating breakpoint locations won't actually install breakpoint traps - gdb will still think that it is already installed. However in JIT case that instruction memory was overwritten and doesn't have a trap anymore. > > Sadly I don't have enough knowledge about gdb architecture to reason if the same problem can possibly manifest with non-jit object files. There's still something that doesn't connect in my mind. I may have a wrong picture of what's happening, so please correct me. >From my understanding of the JIT interface (https://sourceware.org/gdb/current/onlinedocs/gdb/JIT-Interface.html), unregistering code is made by the process calling __jit_debug_register_code (on which GDB has a special breakpoint) with action == JIT_UNREGISTER. Registering code is made by the process calling __jit_debug_register_code with action == JIT_REGISTER. So to unregister a jit region and register a new one (that would happen to have the exact same code at the exact same address as the previous one), the process would need to call __jit_debug_register_code twice, executing between the two events. After unregistration, when the execution resumes, shouldn't there be something that deletes the breakpoint locations related to that objfile that was removed? And then when __jit_debug_register_code for registering the new object, we would re-create brand new breakpoint locations? Or is it that somehow, the unregistration and re-registration is made during the same stop? -- Gerrit-Project: binutils-gdb Gerrit-Branch: master Gerrit-Change-Id: Id9133540d67fa0c4619ac88324b0349b89e4b2b1 Gerrit-Change-Number: 704 Gerrit-PatchSet: 2 Gerrit-Owner: Mihails Strasuns Gerrit-Reviewer: Mihails Strasuns Gerrit-CC: Simon Marchi Gerrit-Comment-Date: Tue, 26 Nov 2019 16:58:51 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: No Gerrit-MessageType: comment