From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) by sourceware.org (Postfix) with ESMTP id 722453870847 for ; Sun, 17 May 2020 19:50:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 722453870847 Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-247-RKumSBfxMHq0uJda6-VRdg-1; Sun, 17 May 2020 15:50:48 -0400 X-MC-Unique: RKumSBfxMHq0uJda6-VRdg-1 Received: by mail-wr1-f70.google.com with SMTP id w9so4488148wrr.3 for ; Sun, 17 May 2020 12:50:48 -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=hEVncF2OBP+FKKtbI3nxAawDgD/A97+5ZkmQbXLqK1w=; b=Iy5i58Z/S4S6bxk9Oj+xvWygEI8m+LNG+gihr4aKCWtV1TYzJF7+lBNVDVXYpP35JW SeE+HR95B40q38yylhi7ibd1E1sflmzpGObMsce1THSBtFTWiEyPcLrrZY5O/KyVJ8L4 g8KPsO+YjdsnW4FtqY0ntBKSkhFKsoJPNyl7xloKwEvmS3pFXDXSIsurJwY0ke92UOq1 7+3SXmLU+Ymb1cUpg4vXb2AGN0oVEzIVU6/3dUCU4dg6Y7yDla8SpbvNCJfwObqhSQ7K QHfdNGR2spv/8c66PVBUTiqSUxJK4xV4xVgDJ1JktmO7n0AaOFAGOHJH/bxtDOX2qhMj eRyQ== X-Gm-Message-State: AOAM532I7vj2xkRMO7ZRt61uMXCUI9BUAJSiQrjVUy+YldA2bVhQo59N vX3eQPAVIW5ak+xmKkbXqOEhNakbWMpo21WltqnyzNZY9SpdoBvQqJCTcSxpqZ6HDXRjUbh9XDc 5tNbR9aSvz0M= X-Received: by 2002:adf:db46:: with SMTP id f6mr15854808wrj.80.1589745047026; Sun, 17 May 2020 12:50:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzoGJeK47BY539U72ow/e9G/oFNgmR43jKYAXjV+hdZ/4Xw+PzgQTkBwrfxMcBgOno0CTKKwg== X-Received: by 2002:adf:db46:: with SMTP id f6mr15854793wrj.80.1589745046820; Sun, 17 May 2020 12:50:46 -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 n17sm13024710wrr.42.2020.05.17.12.50.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 17 May 2020 12:50:46 -0700 (PDT) Subject: Re: exec-file-mismatch and native-gdbserver testing To: Philippe Waroquiers , "Metzger, Markus T" , GDB References: From: Pedro Alves Message-ID: <40713d32-0785-253a-bcde-c6969e12ed6a@redhat.com> Date: Sun, 17 May 2020 20:50:45 +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=-9.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, 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 19:50:51 -0000 On 5/17/20 7:15 PM, Philippe Waroquiers via Gdb wrote: > On Sun, 2020-05-17 at 18:47 +0100, Pedro Alves wrote: >> On 5/17/20 6:24 AM, Philippe Waroquiers via Gdb wrote: >>> For some specific scenarios, it might have an impact, >>> such as the user wanting to debug a copy of the file to avoid >>> 'Text file busy', maybe some interaction with setuid/setgid, ... ? >> >> These seem like rarer scenarios, which would cause warnings/errors >> anyway if you pick the wrong executable? > > For sure, these scenarios are unusual, but it might be better > that the user knows what happens. GDB silently deciding to use > another (physical) file than what the process really executes > is maybe not ideal. > > 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? > > 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. Thanks, Pedro Alves