From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailsec118.isp.belgacom.be (mailsec118.isp.belgacom.be [195.238.20.114]) by sourceware.org (Postfix) with ESMTPS id 6BC37385DC35 for ; Mon, 18 May 2020 10:35:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6BC37385DC35 IronPort-SDR: RUNiAMP70pgX8XL2y3ANRrk8TXajlUnL6mFf3dIYKAkv+b8sOLHl9duDaIGyt4Y4b72QcSsJKi SSvp9EI8ipUKAjocTrVMDNIbmnE/76RzLijuMb+7MczqXPc8R3oxmr8M1de9yb4KrlfgOZQljp j713xSZCpzCKELBfLd41SJdRerNu1lgI6Yx4dFk1In3lifuw3I0KHqdVZgPALd0aLLnwyO//IF jsmtlivLO7jcx2DJ7/y607FHdDdpuvpVxCy0UtWPtErDRGW82r/jfVADvRxdHKbMlc74aboimw IuU= IronPort-PHdr: =?us-ascii?q?9a23=3AJKY/DB1g3JLDbyatsmDT+DRfVm0co7zxezQtwd?= =?us-ascii?q?8ZsesXKPjxwZ3uMQTl6Ol3ixeRBMOHsq8C0rKL+PqwEUU7or+5+EgYd5JNUx?= =?us-ascii?q?JXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6arXK99yMdFQ?= =?us-ascii?q?viPgRpOOv1BpTSj8Oq3Oyu5pHfeQpFiCe9bL9oMRm6sQXcusYIjYZhN6081g?= =?us-ascii?q?bHrnxUdupM2GhmP0iTnxHy5sex+J5s7SFdsO8/+sBDTKv3Yb02QaRXAzo6PW?= =?us-ascii?q?814tbrtQTYQguU+nQcSGQWnQFWDAXD8Rr3Q43+sir+tup6xSmaIcj7Rq06VD?= =?us-ascii?q?i+86tmTgLjhTwZPDAl7m7Yls1wjLpaoB2/oRx/35XUa5yROPZnY6/RYc8WSW?= =?us-ascii?q?9HU81MVSJOH5m8YpMMAeQcPehWsYfzqFkArRSiCwajC+zhxyRUhnL0x6A2z/?= =?us-ascii?q?gtHBvE0QEmAtkAsG7UrNLwNKoKS+61zKjIzTHCb/NOwTfy9pXDfRA7rvGWWr?= =?us-ascii?q?JwaNfRyUgxGAPflVWbtIvoPyuV1uQMt2ib7vJgVfqxhGI9pQB+uCKvxsA1io?= =?us-ascii?q?nUh4Ia1ErE9T5izYYuJt25SEh7bsC4EJdKrC6VKZJ7T8U/SG5npCg00KcJuY?= =?us-ascii?q?KnfCcU0pQnwQbSZfKIfYWK7RzvSuWcLCp4in9rZb6xiBS//Eaix+DgVMS5zU?= =?us-ascii?q?hHoCVGn9TSuH4BywLf58qZRvdg8Uqv1jWC2gTT5OxCPEs6m63bK5s7zb4xkJ?= =?us-ascii?q?oeqV7DETHrl0X2lqCWal8o9fSv6+TiZLjtu5ySN5dshw3gL6gjmNazDfk2Pw?= =?us-ascii?q?UPRWSW+vmw2Kft8ED3RrhBk+c4nbPDsJ/AIMQWvqu5AwhI3Yk98xu/FDKm0M?= =?us-ascii?q?gAnXkAMVJFZAqLj4j3NFHKJ/D1FfK/jEm0nDdqwfDJIKHhD43TInTekrrtZ6?= =?us-ascii?q?tx5kBdxQYpzt1T+ohYB78PLf7rX0/+rt3YDhs3MwyuxObnDc1w1pseWWKOBq?= =?us-ascii?q?+ZMbvSsUeW6e41LeiDfpUVuDHkK/g45v7hk2U5mUQGcKmy3psWaHa4Eep6I0?= =?us-ascii?q?mDenXjnM8NEX0WsQomUOzqlFqCXCZLZ3moW6I8+C80CJm9AIfZWI+inbyB0z?= =?us-ascii?q?2nHpFMem9GDVWMG2/yd4qYQ/cMdD6SIsh5nzwBT7ehUYwh1Qy1tAPg17prNO?= =?us-ascii?q?/U9TMEtZPi29h6+ffTmAoz9TxyE8SSzWWNQ3tokWMPQj88xLp/rlBlylefza?= =?us-ascii?q?h4hORVFdNO6PxSSQo6Lpncz/FgC9/uRA3AcM2GSEy4Tdm8BjExVN0xkJcyZB?= =?us-ascii?q?NFFtm4iVjq2zSnGPdBj7WPGpEv2rjR03j4O4B2zHOQkOFrqlQ6UMRCLynuo6?= =?us-ascii?q?dl9BXIT7KD2xGcnrypaL9awGjI+XuRwmeUlEBeTAN0F67CWCZbLmT6h5yt6U?= =?us-ascii?q?/IZ6SpFK4sPxRI08PELbFFPI7Hl1JDEc/jOdDfe3q801i5HxGR27KBdpGiL3?= =?us-ascii?q?0d3SHcEFAJ1R8a53GfKAkzHDyJuGHPCjFyU1jiNRC/udJioW+2GxdnhzqBaF?= =?us-ascii?q?dsgv/sokYY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2A5AQDdY8Je/yFRiNlmGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAUCBR4Isb3USLINcSIkBiAaBAZpjCwEBAQEBAQEBAQg?= =?us-ascii?q?nBQECBAEBhEQCghknOBMCAwEBAQMCBQEBBgEBAQEBAQQEAWwEAQEHCoRRIQE?= =?us-ascii?q?DAQEFCgE3DII7KQGDDAEBAQECASMzKAsIAw4KAgImAgJXBgGDOYJcJAuuUna?= =?us-ascii?q?BMoROQUODJ4FAgQ4qjFGBTD+BEYJbNT6CZwGBToMsgj4iBI4siXaBCJlmB4J?= =?us-ascii?q?TgQEEhyGQIR2dVpBDiWuUEIFpIoFWbYM8CUclkEwXg0+BdYhjQjA3AgYIAQE?= =?us-ascii?q?DCXQIE44sAQE?= X-IPAS-Result: =?us-ascii?q?A2A5AQDdY8Je/yFRiNlmGwEBAQEBAQEBBQEBARIBAQEDA?= =?us-ascii?q?wEBAUCBR4Isb3USLINcSIkBiAaBAZpjCwEBAQEBAQEBAQgnBQECBAEBhEQCg?= =?us-ascii?q?hknOBMCAwEBAQMCBQEBBgEBAQEBAQQEAWwEAQEHCoRRIQEDAQEFCgE3DII7K?= =?us-ascii?q?QGDDAEBAQECASMzKAsIAw4KAgImAgJXBgGDOYJcJAuuUnaBMoROQUODJ4FAg?= =?us-ascii?q?Q4qjFGBTD+BEYJbNT6CZwGBToMsgj4iBI4siXaBCJlmB4JTgQEEhyGQIR2dV?= =?us-ascii?q?pBDiWuUEIFpIoFWbYM8CUclkEwXg0+BdYhjQjA3AgYIAQEDCXQIE44sAQE?= Received: from 33.81-136-217.adsl-dyn.isp.belgacom.be (HELO md) ([217.136.81.33]) by relay.skynet.be with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 18 May 2020 12:35:19 +0200 Message-ID: Subject: Re: exec-file-mismatch and native-gdbserver testing From: Philippe Waroquiers To: Pedro Alves , "Metzger, Markus T" , GDB Date: Mon, 18 May 2020 12:35:19 +0200 In-Reply-To: <373be598-d048-1231-c9af-40ea5b2cc8fc@redhat.com> 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> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_LOW, 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 10:35:24 -0000 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. > 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). 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. Thanks for the build id patch/investigation/help Philippe