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 3A7C2386F81E for ; Sun, 17 May 2020 21:43:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3A7C2386F81E IronPort-SDR: ORrMqo90BbjVfhYtm6u1g/6urwJzaVpOeRuNo/KJXrIsEvbfOgBhyW/IrSU/RZpwKiKQvBhoHU HD0c5yiCwpms7d3aeLgFGeYmSBftgJORT08nAXocb9C2dc4UlCsy8KCe/m+bga4ye1lorbTpiy JmgjAE3jsGcvbhj9A4Hs1VOsnSgFJuHJ+lPEeWWnRol2ad/HjYPc9wQ/wGXT66nhdF5XuK5yO6 nu7t5UGWhLzoHPP6P6wtPIMIexUlEOoN2LBViq8hKGZVED5V1r9qLzFbTt/6DlE8tZVto5yBMb u7M= IronPort-PHdr: =?us-ascii?q?9a23=3AwBxhnRLZB9mfDgmV0NmcpTZWNBhigK39O0sv0r?= =?us-ascii?q?FitYgXK/78rarrMEGX3/hxlliBBdydt6sZzbOO6Ou5BDJIyK3CmUhKSIZLWR?= =?us-ascii?q?4BhJdetC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TW94jEIBx?= =?us-ascii?q?rwKxd+KPjrFY7OlcS30P2594HObwlSizexfLN/IA+roQnNuMQajpZuJ6Ywxx?= =?us-ascii?q?DUvnZGZuNayH9yK1mOhRj8/MCw/JBi8yRUpf0s8tNLXLv5caolU7FWFSwqPG?= =?us-ascii?q?8p6sLlsxnDVhaP6WAHUmoKiBpIAhPK4w/8U5zsryb1rOt92C2dPc3rUbA5XC?= =?us-ascii?q?mp4ql3RBP0jioMKiU0+3/LhMNukK1boQqhpx1hzI7SfIGVL+d1cqfEcd8HWW?= =?us-ascii?q?ZNQsNdWipcCY2+coQPFfIMM+VFoYf9uVUAoxmxBQewC+zhxTBGiWT73bE43u?= =?us-ascii?q?k7DQ3KwBYtEtAIvX/JrNv1LqASUeWtwafSzTXDbvdW2Tbl6IjQbB8qvPGDUq?= =?us-ascii?q?hqccrW0EkvCgLFgUuKqYz+IjiY0fwNs2ia7+pkVOKvk3YnpB9rrjmh3MgskI?= =?us-ascii?q?7JhpsIylDF6yp52p01KMajSE54Yd+kFoVftz2AO4RtXMwvWmdlszs1xbMao5?= =?us-ascii?q?C0ZjQKyIg5yB7FbfyKa4aG7B3hWeiePzt1h29odrKxihqv/katyOPxW8uo3V?= =?us-ascii?q?tIsydIjNbCu3MT2hLd9sSLVPlw8lm81TuA2A7e6eVJL0AymKHGJZAhxbswmY?= =?us-ascii?q?ASsUTFBiL2glv5g7KWdko+5uik8fjoYrLjppKaKoR6iRn+P7wwlsCiA+k0KB?= =?us-ascii?q?UCUmaa9Oim17Dv4Ff1TbtEg/Awj6LXqorVJd4Bqa68GwJV14Ej5AuhADq+y9?= =?us-ascii?q?QYmGUHLEpCeBKak4jlI1HOL+78Dfe4m1mslSpky+jHPr3nHJrNMmDOnKn8cb?= =?us-ascii?q?t/8UJQ1QQ+wNFF659XF70NOvz+V0HpuNzdFBA5Mgi0w+j9CNV604MTQXqPAq?= =?us-ascii?q?+YMKPWsF+I/vovLPeWaI4bojn9Mf8l5+fzjX84h1AdZ7Kp0IAMaHC7HvVmJV?= =?us-ascii?q?uWYWb2jtgaD2gGphA+Q/DyiF2eTT5TYG6/X7om6TE/FoKpE5zDS5u3gLOfwS?= =?us-ascii?q?i7HodZZnxcBl+QFnfocp2OW+0QZyKKPs9hjjsEWKCkS4A7zxGutxL6y6F9Iu?= =?us-ascii?q?rI4CEYsIzs1MR05u3cix4y7yd5D8Wb02GRUW50mnkESCMx3KB6uUZ90EuM0b?= =?us-ascii?q?Bkg/xEEtxe//xJXRohOpPH1Ox6DM3yWhjdcdiXRlepWM+mDi8rQtI22d8ObB?= =?us-ascii?q?U1J9L3th3PxS3iKrsLmqfDUIQ99rzRxFDrKsp9wmqA364k2R1uCO5CKX+pi7?= =?us-ascii?q?Q7vy3aHY3UiA2l3e7+cK0G3zPWsnvFyGeSrk5VSiZxV7nIWTYUYU6A6ZzWym?= =?us-ascii?q?mKG7CiA5w8NRZbwsOdI7FHLNrzggMVau3kPYHmY2O1mn+oCF63z6mLdZfrdn?= =?us-ascii?q?8GlHHFCEkAkhgL8DCZPBI5HzqgrnjFJCdtBFTifwXm/L8t+zuAUkYowlTSPA?= =?us-ascii?q?Va3L2v90tQ3KTERg=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2BPAACVrsFe/yFRiNlmGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBARIBAQEBAQEBAQEBAQFAgUeCLG9UIRKECEiJAYgGm2QLAQE?= =?us-ascii?q?BAQEBAQEBCCcFAQIEAQGERAKCFSc4EwIDAQEBAwIFAQEGAQEBAQEBBAQBbAQ?= =?us-ascii?q?BAQcKhFEhAQMBAQUKATcMgjspAYMMAQEBAQIBIzMzCAMOCgICJgICVwYBgzm?= =?us-ascii?q?CXCQLrXh2gTKETkFDgySBOgaBDioBjFCBTD+EIT6CZwGBToMsgj4iBI5/iiu?= =?us-ascii?q?YaX0HglOBAQSHIZAhHZ1WkEOJa5QQgWkigVZtgz1PJZBMF4NPilhCZwIGCAE?= =?us-ascii?q?BAwl0CBOOLAEB?= X-IPAS-Result: =?us-ascii?q?A2BPAACVrsFe/yFRiNlmGQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RIBAQEBAQEBAQEBAQFAgUeCLG9UIRKECEiJAYgGm2QLAQEBAQEBAQEBCCcFA?= =?us-ascii?q?QIEAQGERAKCFSc4EwIDAQEBAwIFAQEGAQEBAQEBBAQBbAQBAQcKhFEhAQMBA?= =?us-ascii?q?QUKATcMgjspAYMMAQEBAQIBIzMzCAMOCgICJgICVwYBgzmCXCQLrXh2gTKET?= =?us-ascii?q?kFDgySBOgaBDioBjFCBTD+EIT6CZwGBToMsgj4iBI5/iiuYaX0HglOBAQSHI?= =?us-ascii?q?ZAhHZ1WkEOJa5QQgWkigVZtgz1PJZBMF4NPilhCZwIGCAEBAwl0CBOOLAEB?= 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 23:43:15 +0200 Message-ID: <4f27f3f4aac0a9aae9da414b9668fa4a3fbf1a51.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 23:43:15 +0200 In-Reply-To: <7bf4097d-88ac-7016-bf0d-c1648ac8126b@redhat.com> References: <40713d32-0785-253a-bcde-c6969e12ed6a@redhat.com> <8725565f1879f78a1c37600819a354a47e6d492a.camel@skynet.be> <7bf4097d-88ac-7016-bf0d-c1648ac8126b@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.7 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 21:43:19 -0000 On Sun, 2020-05-17 at 22:19 +0100, Pedro Alves wrote: > On 5/17/20 9:11 PM, Philippe Waroquiers wrote: > > 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). > > Do you really see these "Text busy" errors nowadays? I don't > think I ever saw those on GNU/Linux. The below reproduces it for me: philippe@md:~$ cp /bin/sleep mysleep philippe@md:~$ ./mysleep 100& [1] 7721 philippe@md:~$ echo coucou > mysleep bash: mysleep: Text file busy philippe@md:~$ cat /etc/debian_version 10.4 philippe@md:~$ Maybe typical linkers renaming or removing the exe file before re-creating it, and thereby avoiding (most of) text busy errors ? > > Still, I'm not seeing the same kind of problem that ending > up with the wrong binary loaded in GDB causes. If you end > up with the wrong binary loaded in GDB, then GDB may > for example install breakpoints at the wrong addresses, > and that may even cause the inferior to crash, because the > breakpoint address may fall in the middle of instructions, > resulting in the inferior potentially executing invalid > instructions, or worse, executing valid instructions with > disastrous side effects. If the executable file is modified while GDB is busy using it, could that not cause some problems ? > > 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. > > > So, my main original use case needs filename comparison :(. > > I think that doesn't follow -- you could say that the build id > isn't sufficient for you, and that you need a fallback, but > that doesn't mean that the fallback must be the straight > full path filename comparison as is it today. The filename comparison was an easy way to cover the cases I saw, reasonably OS independent, while build ID is more precise but not working everywhere, so a fallback (whatever it is) for missing build ID situations would be useful. Thanks Philippe