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 [205.139.110.120]) by sourceware.org (Postfix) with ESMTP id C40A3386F44C for ; Sun, 17 May 2020 21:58:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C40A3386F44C Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-184-hMacpD6zNOS1S94LbMv70g-1; Sun, 17 May 2020 17:58:21 -0400 X-MC-Unique: hMacpD6zNOS1S94LbMv70g-1 Received: by mail-wr1-f72.google.com with SMTP id p8so4611688wrj.5 for ; Sun, 17 May 2020 14:58:21 -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=JWGQ+sfrS4msSmp4inRMbE5RQsMzTQK71j1Vd32VoBY=; b=CuyeK6vw9dVFMa6+4qhV84gBiHhz0KpyyQXYw3/PeeSenr9wiUaD8GmmiTPfM7hEgh 6G2fSJ1jKRL9S+wNYD83ZFrqICXhh5Y9dojB2l1OxYs/phT6JoDT98+07Vhu5ovVRpqI U9SMpFZVKl9cezeVp2x6QwStwkYVGK/Ki4Qzs74Ys0E9bMs59BwU1H1l9B5WTmsJoxPn 3ACEmpes8khDqXJjin3dwkty8fQIaHuQoNar4b6hEpCeGJMXwszY0AB0HqmBfuoxd4li WXXfr7bxXptyGqTiVQJ6CW/Euzc3gkW4VAAVx7RFaaOOGBucvPBnkIBhuUSJbgnczSZ8 w5kw== X-Gm-Message-State: AOAM5332KrdYlFHSSUaJeg/7SBKJPrbJ+txJryWQqcaRjOPYbVewfCXg HAKIrNDsjprzp3RqeMe+tSDZO4Nytji9dpQmMdz3cDQ6xMfwLPZ4vSYeS14YD/3Z9nUsgXrOGgh h+pSJqDrKINw= X-Received: by 2002:adf:ea0d:: with SMTP id q13mr15888171wrm.211.1589752700193; Sun, 17 May 2020 14:58:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw72bezy59LlHSMtSUjoK/6Op/B7Qsz4LW4BATxpCs7k1wpziDUh2tJltdOmGHop+yqKapuiA== X-Received: by 2002:adf:ea0d:: with SMTP id q13mr15888156wrm.211.1589752699933; Sun, 17 May 2020 14:58:19 -0700 (PDT) Received: from ?IPv6:2001:8a0:f909:7b00:2327:23ca:3e56:ef5f? ([2001:8a0:f909:7b00:2327:23ca:3e56:ef5f]) by smtp.gmail.com with ESMTPSA id p9sm13932734wrj.29.2020.05.17.14.58.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 17 May 2020 14:58:19 -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> From: Pedro Alves Message-ID: <373be598-d048-1231-c9af-40ea5b2cc8fc@redhat.com> Date: Sun, 17 May 2020 22:58:18 +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: <4f27f3f4aac0a9aae9da414b9668fa4a3fbf1a51.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=-8.7 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: Sun, 17 May 2020 21:58:25 -0000 On 5/17/20 10:43 PM, Philippe Waroquiers via Gdb wrote: > 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:~$ Ah, OK. Yeah, OK if you try to write directly to the file like that. But no one does that. > > Maybe typical linkers renaming or removing > the exe file before re-creating it, and thereby avoiding (most of) > text busy errors ? Yeah, gcc/ld unlink the file before recreating it, so in essence they don't write to the preexisting inode, they create a new one. > >> >> 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 ? 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. > > > >>> 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. Great, thanks. > >> >>> 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. 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. Thanks, Pedro Alves