From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by sourceware.org (Postfix) with ESMTP id A6DBA3840C37 for ; Thu, 21 May 2020 14:02:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A6DBA3840C37 Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-211-1bKdMBNlOPCxMSMwxMmaCg-1; Thu, 21 May 2020 10:02:53 -0400 X-MC-Unique: 1bKdMBNlOPCxMSMwxMmaCg-1 Received: by mail-wr1-f70.google.com with SMTP id f4so262246wrp.21 for ; Thu, 21 May 2020 07:02:53 -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=K5vZl/3rFC4bnoidqKnzqQ1qgfEwfgbVO9ZA524KBdQ=; b=A/D2Tb3Fs7oHqXEg2drnsmSJyw3PZqHPPer9oqaV/n63bR3TiUWgS1AYII93aHkzmx G0cEWOy1XLmN7d+HjQ4OrbM1L3L5FfaB3G/gpPBwB7zTrRJAbZGKtyzOmFvyK0D/lh4Y 0oVaWk6deVZhHGN7w9asM5+FKvt5CmUhO3wznGGYjIfC2Jz5fmKmhmuHwfqhcb4MEjo+ TYRenQUNL9yHQVAwg58QEecQ8b+ujuWYtjtW4GAX6x2Emvnh6ylNNUNsYW/PKIHK58fR r/dZeeASpUyY7AaTa7xDo46rtVgtr4D1tU4q9c7/11xrULfT3Pe5bZnFCQfrFDeW4olA YYZQ== X-Gm-Message-State: AOAM531cyxEcuaaOUY1SiX0jgf7mgVwpZtOk5oXN5n/gJhWQifl8W1ko W75aoJVCdM2Ct6S3yaBkZR4N2Ndh0v3m64mCk6YAf7v3vnWwrVe5ozmEuuk4O5h6E4f/R0Kbc59 UVfXtKz3MoXp4wxhspIGzwQ== X-Received: by 2002:a5d:522d:: with SMTP id i13mr8880651wra.306.1590069771962; Thu, 21 May 2020 07:02:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxyA2nLeyKPjyRF935FSmVVsXynsMj38iPpvZUTADQhoOmjpblRr9YbBJ9r7xgJQkEjSGsSSQ== X-Received: by 2002:a5d:522d:: with SMTP id i13mr8880624wra.306.1590069771645; Thu, 21 May 2020 07:02:51 -0700 (PDT) Received: from ?IPv6:2001:8a0:f909:7b00:56ee:75ff:fe8d:232b? ([2001:8a0:f909:7b00:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id x18sm6161229wru.72.2020.05.21.07.02.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 May 2020 07:02:50 -0700 (PDT) Subject: Re: [PATCH v2 3/3] Make exec-file-mismatch compare build IDs To: Philippe Waroquiers , Tom Tromey , Pedro Alves via Gdb-patches References: <20200517180450.14925-1-palves@redhat.com> <20200517180450.14925-4-palves@redhat.com> <87tv0b7vy0.fsf@tromey.com> <6d669d00-236a-cede-5c5e-3d65d3ee5a53@redhat.com> <4719db5fbbd5f3b4026bf4b7637ce922d24e8c6b.camel@skynet.be> From: Pedro Alves Message-ID: <437fb053-a1e0-67de-0f0e-6a14fb95bf90@redhat.com> Date: Thu, 21 May 2020 15:02:49 +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: <4719db5fbbd5f3b4026bf4b7637ce922d24e8c6b.camel@skynet.be> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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, 21 May 2020 14:02:56 -0000 On 5/21/20 2:32 PM, Philippe Waroquiers wrote: > Comparing build-id introduced a change of behaviour when GDB has > loaded a file, and the user recompiles this file followed by an attach. > > Before this patch, when GDB had a file loaded and the user recompiled > the file and attached to a process using this recompiled file, > GDB used to reload the file automatically. > Now, GDB reports a mismatch, indicating a "mismatch" > instead of automatically re-loading the new file version. > > Technically, GDB mismatch is correct, but I am wondering if this change > of behaviour is desirable. At least, it introduces a difference > of behaviour between run (that will just indicate the file has changed > and reload automatically) and attach (that will warn and ask). > > > (gdb) atta 10615 > Attaching to program: /bd/home/philippe/gdb/git/build_moreaa/gdb/gdb, process 10615 > [New LWP 10616] > [New LWP 10617] > [New LWP 10618] > [New LWP 10620] > [New LWP 10621] > [New LWP 10622] > [New LWP 10623] > warning: Mismatch between current exec-file /bd/home/philippe/gdb/git/build_moreaa/gdb/gdb > and automatically determined exec-file /bd/home/philippe/gdb/git/build_moreaa/gdb/gdb > exec-file-mismatch handling is currently "ask" > Load new symbol table from "/bd/home/philippe/gdb/git/build_moreaa/gdb/gdb"? (y or n) > > > while previously, GDB was doing: > (gdb) atta 14099 > Attaching to program: /bd/home/philippe/gdb/git/build_moreaa/gdb/gdb, process 14099 > [New LWP 14100] > [New LWP 14101] > [New LWP 14102] > [New LWP 14104] > [New LWP 14105] > [New LWP 14106] > [New LWP 14107] > `/bd/home/philippe/gdb/git/build_moreaa/gdb/gdb' has changed; re-reading symbols. It looks to me like GDB is doing the validation too soon. It should figure out that the local file changed, and thus reload it (the "re-reading symbols"), and only after, should it do validation? After re-reading, the build ids should match again. Or do the "has changed, re-reading" thing earlier, but not sure that's practical. Thanks, Pedro Alves