From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ItDNNnU6hF/5ZQAAWB0awg (envelope-from ) for ; Mon, 12 Oct 2020 07:13:57 -0400 Received: by simark.ca (Postfix, from userid 112) id D3EFB1EF6F; Mon, 12 Oct 2020 07:13:57 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id D5E601E58C for ; Mon, 12 Oct 2020 07:13:56 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6477A3857C45; Mon, 12 Oct 2020 11:13:56 +0000 (GMT) Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by sourceware.org (Postfix) with ESMTPS id 96FD03857C45 for ; Mon, 12 Oct 2020 11:13:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 96FD03857C45 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=alves.ped@gmail.com Received: by mail-wr1-f66.google.com with SMTP id h5so8638847wrv.7 for ; Mon, 12 Oct 2020 04:13:52 -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=dqfZhgYsWj8doHXV9uzn+17184QqsmF1AnnOE2eeINk=; b=Dqmj4nHZoDKEeVLoBNOMfk6op5vCfrNhDTb0NY0Yr/vpdy3KGwUyw0va/5vOxTx3R2 J21O8oM6l7T9Bur545KIvIcO+liPf5acJD9evVnLXhN8oMMz4DRaRTwI+Hxw71iJ8H3k p6m+8O2icUCtkpyUfDeaBpc1nUPS3Uf34kndMojzQuA6CiAFxx7Zhvw5fUtVRQUPNSQR 39JK4lkcMVUzY12cMKhuVESTOGCI20jO+tuRsarSee1TAHKN42FwdoSMpAYoCXVgvuGX TuJeMtJmjpvXvNj8AwqC2zH1WhGFEWdYYAV0Xu1OWAoSuQthMyCQrLRuoIWKp3RtVdg0 AXXA== X-Gm-Message-State: AOAM530FZmhtE2bWidz0jeBwXOY1T/LLtG7zDKPxhfMafg+N8nHHO7tT JvkFjo/W16p4FRmmJRZBZuShgqZAgFxjmA== X-Google-Smtp-Source: ABdhPJwEAMz8PT8fEJrIkf2C/wyGZyGUMNhGra/o6NhnQ1D017eGWZ8r/xTH04KS6vm6rGCJCeeA8Q== X-Received: by 2002:adf:9541:: with SMTP id 59mr29438805wrs.396.1602501230919; Mon, 12 Oct 2020 04:13:50 -0700 (PDT) Received: from ?IPv6:2001:8a0:f91e:6d00:c80a:ea25:47ef:5f73? ([2001:8a0:f91e:6d00:c80a:ea25:47ef:5f73]) by smtp.gmail.com with ESMTPSA id e13sm25552320wre.60.2020.10.12.04.13.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Oct 2020 04:13:49 -0700 (PDT) Subject: Re: [PATCH 7/7] Reset Windows hardware breakpoints on executable's entry point To: Hannes Domani , Gdb-patches References: <20200525185659.59346-1-ssbssa@yahoo.de> <20200525185659.59346-8-ssbssa@yahoo.de> <1116841542.798992.1591534575390@mail.yahoo.com> <13b5d541-81c8-e7cb-1e9b-29e85b1c940b@palves.net> <1338819464.1964114.1602269513009@mail.yahoo.com> From: Pedro Alves Message-ID: Date: Mon, 12 Oct 2020 12:13:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <1338819464.1964114.1602269513009@mail.yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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: , Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 10/9/20 7:51 PM, Hannes Domani wrote: > Am Freitag, 9. Oktober 2020, 20:22:21 MESZ hat Pedro Alves Folgendes geschrieben: > >> However, does the breakpoint go away when the inferior exits, though? >> I'm wondering what happens when, say: >> >> #1 - you load a Windows binary in inferior 1. >> #2 - you run the inferior, and it exits >> #3 - you now load a non-Windows binary in inferior 1 (say, a GNU/Linux program) >> #4 - you run inferior 1 >> >> Don't we end up in startup_breakpoint_re_set in step #3 or #4? >> If so, that calls get_windows_inferior_data() which a new >> windows_info object, and then creates a location at address 0, >> I presume.  All while the inferior isn't a Windows inferior. >> >> Or what if you load a Windows program in inferior 1, and a GNU/Linux >> program in inferior 2?  Doesn't a similar problem happen? > > You're probably right. > I've never build a gdb which understands both Windows and Linux > executables (I think), so I can't test it. You just need to build gdb with --enable-targets=all > > It looks like it keeps the breakpoint on the same location as the last > Windows executable. > > What would you suggest how to fix this? I think you need to add some checks for "is this a Windows inferior". Maybe with something like: static bool is_windows_inferior (inferior *inf) { switch (gdbarch_osabi (inf->gdbarch)) { case GDB_OSABI_CYGWIN: case GDB_OSABI_WINDOW: return true; } return false; } In startup_breakpoint_re_set, don't create locations if the inferior isn't a Windows inferior. Then in your gdb::observers::inferior_exit observer, delete the breakpoint locations for the exiting inferior. I still suspect that having a breakpoint per inferior/pspace, and a keeping a pointer to it in the per-inf/pspace structure (you can get at the current entry point address from the breakpoint's first location's address instead of a separate field for the entry point address), instead of a single breakpoint with multiple locations would simplify things. But if you want to keep your current approach, that's fine with me.