From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailsec108.isp.belgacom.be (mailsec108.isp.belgacom.be [195.238.20.104]) by sourceware.org (Postfix) with ESMTPS id B9D25386F460 for ; Sun, 17 May 2020 20:11:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B9D25386F460 IronPort-SDR: hKyeGgOAuDYvqAIfuGGTUhq26XUm+Z/CV1Oe2UL5l4bQ4uZRwAJwP8KSuMy7E0xl8sU8jyqXI7 hY8PbwZ8ALTBnPr0zMQ5QC4l4UnDZoaSsYwbbUxNd+tDVu6f6PA2EkZUcwIkWdEcVSVa0pSALt 0Dfs6XKhZ/D3QCuAIUVjN1/nLSlkLB5pYRQRrQBjXz1EOzo5cmItnIKyEFOEj948XjgdHGx8qW HPEO85Ub3EkgIc2lBn6yH9xgWvCzR43imMNfhFz7B8gVdOAI/3rJOhsr7XMP6OqIdCYOt94nry MuY= IronPort-PHdr: =?us-ascii?q?9a23=3AdMHErxC91MqJrycsxkwxUyQJP3N1i/DPJgcQr6?= =?us-ascii?q?AfoPdwSP37r8WwAkXT6L1XgUPTWs2DsrQY0reQ6vi7EjVcut6oizMrSNR0TR?= =?us-ascii?q?gLiMEbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpTEdFQ?= =?us-ascii?q?/iOgVrO+/7BpDdj9it1+C15pbffxhEiCCybL9vLBi6txjdutUYjIdtN6o8xR?= =?us-ascii?q?XEqWZUdupLwm9lOUidlAvm6Meq+55j/SVQu/Y/+MNFTK73Yac2Q6FGATo/K2?= =?us-ascii?q?w669HluhfFTQuU+3sTSX4WnQZSAwjE9x71QJH8uTbnu+Vn2SmaOcr2Ta0oWT?= =?us-ascii?q?mn8qxmRgPkhDsBOjUk62zclNB+g7xHrxKgvxx/wpDbYIeJNPplY6jRecoWSX?= =?us-ascii?q?ddUspNUiBMBJ63YYkSAOobJetWrJTzqVsQoxWwBwasCv/gxTFHiXH5xqA6z+?= =?us-ascii?q?YsHBva0AA8Bd8DsnLZp8j1OqcIVuC1ybHFwy/Db/NX3Tf96ZDIcgg/rvqRXb?= =?us-ascii?q?1/a9DRyU42FwPYj1Wft5blPyiI3ekKq2ib7+tgVeaui24/swF+vCKjx8k2hY?= =?us-ascii?q?nTgYIV003E9SRnz4YvPt21U1V7Yd2kEZtWqS6aK5F6Tdg8TGxxvisx17IJt4?= =?us-ascii?q?KhcicQ1JQn2wDQa+aBc4WQ/B7vSuWcLCt3iX55ZL6yhRa//Ee9x+P8SsW531?= =?us-ascii?q?lEoCpYn9TCsn0AyRLd59aJR/Z+/Uqs1zeC2gDd5+xLJU05lKzWIIMizL4ojp?= =?us-ascii?q?cfr1nPEy3slEnrgqKbd18o9+u15+j9bLjrqJmRPJJuhA7kKKQhgMm/DPw9Mg?= =?us-ascii?q?gJQmeU5/yx1Kbm/U3lWLVKieA2krXBvJDaO8sboqm5DhdQ0ok+8xq/DjGm38?= =?us-ascii?q?oEnXQfMl5JZRCKg5L0N1zAIf30F/Syj0m2nDplyf3KJrjhDY/MLnjHnrfhZ7?= =?us-ascii?q?F960tExQorzdBf5pZUCrAZIPLrRED9rtLZAQUjMwyz2ubnFdR92Z0EWWKUGa?= =?us-ascii?q?KZK6DSsF+O5u0xP+mAfpQatyjlJ/g/+/HulWM5mUMafaSxxZsYcnS4Hup4LE?= =?us-ascii?q?WCenfsmMkOHnoKvgUkUOzmkkGNUTlWZ3yqRaIz+ik7CJ66DYfEXo2thaaO3D?= =?us-ascii?q?24Hp1LfWBKEEyMHW3td4qaR/cNaS2SLdF7kjEfVLihTZMh2g+qtAPg17VnKe?= =?us-ascii?q?/U8DUCtZ3/zNh1+/HTlRYq+Dx7EsuSyHqAT3pznmMVXT85wL5woEJnxVeZz6?= =?us-ascii?q?d0mftYFcZc56ABbgBvDZPQ1esyItTsVxmJKs+ATEirWf28DD0xR853yNgLNQ?= =?us-ascii?q?I1UfCvkgLM0jDuS5ocjb+WH9QIuOqI2nHrJNtmjWqA0aQ9nVYrWONOM3Grgu?= =?us-ascii?q?h08A2FQ8bmv2/Rw6mmf4wH2zPX/2qcxHCD+kZCX1gjf7/CWCUnZkrSrMzh6w?= =?us-ascii?q?v9RqWpEKkmPxFagZqaKqpOa8XxgBNZTe3kIcnfbniqs3yzFBCF2vWGYdy5KC?= =?us-ascii?q?0mwCzBBR1cwEgo9nGcOF17X3/5rg=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2BPAABGmcFe/yFRiNlmGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBARIBAQEBAQEBAQEBAQFAgUeCLIFDIRKECEiJAYgHgQGaYws?= =?us-ascii?q?BAQEBAQEBAQEILAECBAEBhEQCghUnOBMCAwEBAQMCBQEBBgEBAQEBAQQEAWw?= =?us-ascii?q?EAQEHCoRRIQEDAQEFCgELBjKCOykBgwwBAQEBAgEjMzMIAw4KAgImAgJXBgG?= =?us-ascii?q?GFSStdXaBMoVSgyWBQIEOKgGMUIFMP4ERgls1Podigj4iBJkqmAJnfQeCU4E?= =?us-ascii?q?BBJdCHZ1WkEOde4FpIoFWbYM9TyWDZ5sjQmcCBggBAQMJdAgTi2ktghYBAQ?= X-IPAS-Result: =?us-ascii?q?A2BPAABGmcFe/yFRiNlmGQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RIBAQEBAQEBAQEBAQFAgUeCLIFDIRKECEiJAYgHgQGaYwsBAQEBAQEBAQEIL?= =?us-ascii?q?AECBAEBhEQCghUnOBMCAwEBAQMCBQEBBgEBAQEBAQQEAWwEAQEHCoRRIQEDA?= =?us-ascii?q?QEFCgELBjKCOykBgwwBAQEBAgEjMzMIAw4KAgImAgJXBgGGFSStdXaBMoVSg?= =?us-ascii?q?yWBQIEOKgGMUIFMP4ERgls1Podigj4iBJkqmAJnfQeCU4EBBJdCHZ1WkEOde?= =?us-ascii?q?4FpIoFWbYM9TyWDZ5sjQmcCBggBAQMJdAgTi2ktghYBAQ?= 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; 17 May 2020 22:11:26 +0200 Message-ID: <8725565f1879f78a1c37600819a354a47e6d492a.camel@skynet.be> Subject: Re: exec-file-mismatch and native-gdbserver testing From: Philippe Waroquiers To: Pedro Alves , "Metzger, Markus T" , GDB Date: Sun, 17 May 2020 22:11:25 +0200 In-Reply-To: <40713d32-0785-253a-bcde-c6969e12ed6a@redhat.com> References: <40713d32-0785-253a-bcde-c6969e12ed6a@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.8 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: Sun, 17 May 2020 20:11:30 -0000 On Sun, 2020-05-17 at 20:50 +0100, Pedro Alves wrote: > > E.g. I am wondering if the below will be visible and cause > > an (understandable) warning/error/behaviour for the user: > > If the user has debugged a first process with orig_exe, > > then the user copied orig_exe to copy_orig_exe, and then GDB is > > attached to a process that runs copy_orig_exe, the user does not expect > > to have orig_exe protected/accessed anymore, and so might change it > > or remove it or ..., while GDB still use orig_exe instead of copy_orig_exe. > > But this seems like a pretty benign problem? But I'm not sure > I understood it. What exactly goes wrong in this scenario? The user expects orig_exe to not be 'busy' anymore, and so expects to be able to freely modify it, without e.g. impacting the GDB session debugging the executable running copy_orig_exe. (I guess that orig_exe will not cause 'Text busy' error, as no process is still executing it from the kernel point of view). > > > So, I was wondering if such a case of equal build ID > > but different (local?) file names are not worth a warning. > > IMO it isn't, because it is very common to have different > filenames (if you consider the whole path) for executable > loaded in gdb compared to the executable that the process is > running when you consider remote debugging. > > > > I'm thinking, if we support build ID validation, do we really want > > > to fallback to filename validation? It seems to me that it causes > > > more false positives than desirable. > > You mean that the filename comparison is useless (or even harmful) > > if we found the build ID in the files ? > > Effectively, if build ID are different but filenames are equal, > > that is likely a false positive 'file are matching' > > (only possible in remote debugging setup I suppose). > > No, I mean, let's consider the feature from scratch again. > I'm saying that IMHO filename comparison on its own is pretty > weak and annoyingly chatty. I'd think e.g., a basename > match + segments match (compare addresses and sizes of > of text, data, etc, segments) would already be much better. > But that's a path that's been considered in all other scenarios > where we have to match binaries, and ultimately, build ID > was invented to fix this kind of scenario without heuristics, > because heuristics can always fail. > > So given that we can do buildid matching, shouldn't we just forget > all other kinds of matching, and just stick with build id matching, > with no fallback? I.e., add build id matching, remove the filename > matching, and raise the bar for any fallback matching -- as in if > you want some fallback, it has to be better than just filenames. > > IIRC, the main motivation for the feature is when you attach to > a process running bar, while you have foo (completely unrelated to bar) > loaded in gdb. GDB previously would assume that foo is the symbol file > for bar, so it gladly continued debugging bar with the foo binary. > Buildid detects this, and also detects the scenario of attaching to > a process that is running an older version of bar than the version > you have loaded in gdb (because you rebuilt the program before > attaching, for example). > > More contrived use cases can be imagined, but it seems to me like > if you want to catch them, then you're better off making sure your > binaries include build ids. Which is true by default on modern > GNU/Linux OSs at least. At my work, objdump -h some_exe does not show a build ID, not clear why (RHEL 7.8, but using gold linker from Adacore gnatpro). So, my main original use case needs filename comparison :(. Philippe