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 21B9B384A034 for ; Mon, 18 May 2020 14:05:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 21B9B384A034 Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-113-ssJ9FLehNZecV74FtCgCWw-1; Mon, 18 May 2020 10:05:56 -0400 X-MC-Unique: ssJ9FLehNZecV74FtCgCWw-1 Received: by mail-wm1-f71.google.com with SMTP id t62so5487532wmt.7 for ; Mon, 18 May 2020 07:05:56 -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=IXxrlK6V7AobqrmQcyyz8HE5ElLGx3zyUFWwScRAWMk=; b=aLHsLilIMZ/sJU1QKuC8wccbAUTolb9L7Wf6SsPs3NBrJiLjZTUU210j8/quHjsVnu dDusR836Z+trZ14vRh7ShPKBlSwnSWYzBL8AqW9z//OHinUsdEWjVR28IBFF49sXWcg3 vSXRly8vyz5s63Kw25u1PUNcIyq5z5xfy77K1teqKDxhSKsCkiRdh1DjBYOTHyDAtPsQ l75RESlI2vPe32kT4LY5zXwlp1sZrzk4sSGh7HOYjDC/7fU3k65qUo0oEgTcANgn0g2Y zYQBGcZ53WeFgdH9cusYNe7WOmciggsvqTUdakjrzlQnoa6gWtd+4DChqiAD3iJYQg/s qxdA== X-Gm-Message-State: AOAM530cXxKeqFQbZqYTKNs+XRNEE9WGUNdtm4ye1x4OztmiR6Gr0X9h Y3NbqUy/d9WpV23g/6J2XrtzSvAxakCfu0nZpsf5FdjsLt67DB1KERUy+1l773NTwX+b/A/jIv8 VHXscSyzQTDA= X-Received: by 2002:a1c:444:: with SMTP id 65mr20349304wme.21.1589810754817; Mon, 18 May 2020 07:05:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwEKoPFCZsMPm6+AtnB/KXhroWW4fNnGHCFUKiaBYUbGfbiVzrTtiUZlVNJleIHvIBGKHRsvg== X-Received: by 2002:a1c:444:: with SMTP id 65mr20349279wme.21.1589810754497; Mon, 18 May 2020 07:05:54 -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 r3sm16072581wmh.48.2020.05.18.07.05.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 May 2020 07:05:53 -0700 (PDT) Subject: Re: exec-file-mismatch and native-gdbserver testing To: Philippe Waroquiers , "Metzger, Markus T" , GDB References: <40713d32-0785-253a-bcde-c6969e12ed6a@redhat.com> <8725565f1879f78a1c37600819a354a47e6d492a.camel@skynet.be> <7bf4097d-88ac-7016-bf0d-c1648ac8126b@redhat.com> <4f27f3f4aac0a9aae9da414b9668fa4a3fbf1a51.camel@skynet.be> <373be598-d048-1231-c9af-40ea5b2cc8fc@redhat.com> From: Pedro Alves Message-ID: <240836b1-0fd4-b276-4fde-32abc2d784be@redhat.com> Date: Mon, 18 May 2020 15:05:52 +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: 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.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, 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@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2020 14:05:59 -0000 On 5/18/20 11:35 AM, Philippe Waroquiers via Gdb wrote: > On Sun, 2020-05-17 at 22:58 +0100, Pedro Alves wrote: >> If the executable file is modified while GDB is busy using it, >>> could that not cause some problems ? >> >> How does filename detection help with this? If GDB is busy >> using it, you're already past the initial filename verification. >> And if you modify the binary but don't change the filename, >> then the filename verification doesn't help either. There >> are many ways to shoot yourself in the foot, I don't think >> we need to protect against all of them. > I think we have 2 different aspects: > * can GDB detect and protect against all problems ? Answer is no :). > * can GDB silently do something that might afterwards lead > to unexpected behaviour ? IMO, answer is preferably no: > If GDB does something (like *not* using the file that > a process is using), IMO, GDB should at least tell that to the user. > (like GDB is telling to the user that it is reloading a changed file). > >> >>> >>> >>>>> So, my main original use case needs filename comparison :(. >>>> >>>> According to: >>>> >>>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/developer_guide/compiling-build-id >>>> >>>> "Each executable or shared library built with Red Hat Enterprise Linux Server 6 or later is assigned a unique identification 160-bit SHA-1 string, generated as a checksum of selected parts of the binary. " >>>> >>>> Maybe older gold versions didn't emit the build id by default, while >>>> GNU ld did. I tried it with master gold, and it emits the build id >>>> by default. does explicitly specifying --build-id on the link work? >>>> Since you're already not using the default tools, you could tweak >>>> your build system to explicitly request a build id? >>> I will check tomorrow if I can persuade the build system >>> to generate a build ID. >>> If yes (and assuming all what we have to debug but we do not build >>> ourselves has a build ID), then build ID will cover my use case. > I managed to have a build ID generated by adding --build-id linker arg, > thanks for the hint of explicitly passing --build-id. > > For info, these are the linker versions: > gnatpro-20.0-20191009-L7/libexec/gcc/x86_64-pc-linux-gnu/8.3.1/ld.gold --version > GNU gold (GNU Binutils 2.30.52.20180618) 1.15 > gnatpro-20.0-20191009-L7/libexec/gcc/x86_64-pc-linux-gnu/8.3.1/ld --version > GNU ld (GNU Binutils) 2.30.52.20180618 > > > So, comparing build id is good enough for my @work use case. Great, thanks for confirming that! > > >> OK. But I argue that the filename matching is more harmful than >> helpful (see e.g., the remote debugging scenarios I presented). >> I would rather remove it before a release is out with it, and >> consider a better fallback if one is found & needed. If >> we keep it, we also have to come up with ways to unbreak the >> testsuite on the different configurations that are presently >> broken for it. That alone would be sufficient grounds for a >> reversion until it is fixed, IMHO. > GDB silently keeping a wrong exec-file e.g. when using attach > is very confusing. > The exec-file-mismatch is supposed to avoid such confusion, and > if that confusion can be avoided when there are no build ids, > that is preferable IMO. > > Maybe what we can do is: > - If build ids are equal, then no problem (and no need to compare file names). > - If build ids are different, then ask or warn user about mismatch > (and no need to compare file names). > - If build ids are not available, then try to detect confusing situation via > some fallback (such as the filename comparison). This was actually what my patch was doing. If we could compare build ids and that detected a mismatch, then no filename comparison was made. What I think is subpar is that the fallback is purely based on comparing filenames. > > Will that not solve (most of) the problems of the testsuite/remote debugging > and detect (more) exec file mismatches in various setups/platforms > (like the default setup at my work) ? > > If the filename fallback is giving too much problems but only > in case of remote setup, we can maybe disable file name comparisons > in such remote debugging. > > But as said above, for my @work use case, I (selfishly :)) see that > build ids are good enough for me. > > So, if you think filename comparison will do more harm than good, > fine for me to remove it. Alright, I really think the filename comparison is too simplistic and causes more harm than good (especially the querying). I've updated the patch over at gdb-patches to remove it for now. I'd say, only revisit if we can't convince people that they should enable build ids. Over time, given that the GNU toolchain (at least) enables it by default nowadays, I think that the issue will sort itself out, and we can just forget about fallbacks. :-) > Thanks for the build id patch/investigation/help Thanks, Pedro Alves