From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by sourceware.org (Postfix) with ESMTP id DB1473870847 for ; Sun, 17 May 2020 17:49:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org DB1473870847 Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-100-A-ld6yWmP0uA6Lg94iwgng-1; Sun, 17 May 2020 13:49:46 -0400 X-MC-Unique: A-ld6yWmP0uA6Lg94iwgng-1 Received: by mail-ej1-f71.google.com with SMTP id n15so4176837ejh.23 for ; Sun, 17 May 2020 10:49:45 -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=nlRT8XykApBFZEQBsCmCxZCmnIh/JBhYzVumVfImTgs=; b=kBVq8IuEmvBxQOS9KQIF0/Dha9vhgpv3ZrE6SGGGWK/A3RKesCji0MumANiXBoUGzA YguDpXfspwitWkGxQEpxZfpXCIipfn+/TsaqCIAszBcfaoDJcjVRgiTKSKX/zu9pnTDI L7kObKUwzvLYrngGvhGPN1EX5dEgYqdsDV8gOomoB/2/gbjYMttzmq8mbC6KchIBzjx1 kwNYjcGIkSYXxlKVtzz4r07KS0bet1tmCv3Veyp5YYGVH899V+PEtsmGLIwUg5Yho8Q1 TINdclg1PbmJO2Tlqp6pdsarVCRryHW+s/dKZ0aCW/I1d9Kcf+LpRofnTcGeKOT1XHlg vhXw== X-Gm-Message-State: AOAM530GSwdPy1ATHeuNMFF0A0bR9Js8ED6KHubKz6zQqlJ7Voton0v0 v/Szyr2Tv9EUTv7HjKKyxip6YxqfRjMuOGw48R3cLQIR12ue4xvjLqk3PzxOE8J40RXKarqZwQJ /a4h+lkwWF8g= X-Received: by 2002:a17:907:2065:: with SMTP id qp5mr11826155ejb.136.1589737784388; Sun, 17 May 2020 10:49:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJztPgiRVNhkoQ7pkwQJQdtLVoyuBE4baioW1BGTumqFr7BEjYKaDJAC9yjA+gS28TsA366j2A== X-Received: by 2002:a17:907:2065:: with SMTP id qp5mr11826139ejb.136.1589737784040; Sun, 17 May 2020 10:49:44 -0700 (PDT) Received: from [192.168.0.4] (bl21-190-29.dsl.telepac.pt. [2.82.190.29]) by smtp.gmail.com with ESMTPSA id ch8sm1106126ejb.53.2020.05.17.10.49.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 17 May 2020 10:49:43 -0700 (PDT) Subject: Re: exec-file-mismatch and native-gdbserver testing To: Philippe Waroquiers , "Metzger, Markus T" , GDB References: From: Pedro Alves Message-ID: Date: Sun, 17 May 2020 18:47:31 +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=-4.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no 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 17:49:54 -0000 On 5/17/20 6:24 AM, Philippe Waroquiers via Gdb wrote: > On Sat, 2020-05-16 at 21:10 +0100, Pedro Alves via Gdb wrote: >> >> So I cooked up something. Below's the resulting preliminary patch. >> >> Seems to work nicely -- it fixes gdb.base/argv0-symlink.exp at least. >> I haven't run the testsuite yet. > I have looked at the patch and played a little bit in a native setup. > It worked as expected, the patch looks ok to me. > > Note that buildid comparison means that the exec-file used by > GDB might not be the (same physical) exec-file of the process > being debugged. Right. A common use case is for the target to run a stripped executable, while gdb is loaded with an executable with debug info. The build IDs will match in this case, while filenames most probably won't. Related, when remote debugging, it's very common that the path on the remote system is different from the path of the file loaded on gdb. Many people doing embedded development will have setups where the IDE copies a local file to the target for debugging, and remotely puts the file under $HOME, or under /tmp, just like that dejagnu does when remote testing. You can get a sense of that if you try the testsuite with --target_board=remote-gdbserver-on-localhost: (gdb) spawn /usr/bin/ssh -l pedro localhost /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/../../gdbserver/gdbserver --once localhost:2346 break Process /home/pedro/break created; pid = 12712 Listening on port 2346 target remote localhost:2346 Remote debugging using localhost:2346 warning: Mismatch between current exec-file /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/break/break and automatically determined exec-file /home/pedro/break exec-file-mismatch handling is currently "ask" Load new symbol table from "/home/pedro/break"? (y or n) > 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? 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. > > Maybe good enough to mention this in the user manual and/or in the > 'help set exec-file- > mismatch' ? > Or maybe GDB should give a message to the user for different files > but same buildid ? > > >> >> There's (at least) one issue that I'll need to fix. It's to >> get rid of the "transfers from remote targets can be slow" warning >> when we open the remote file to read the build id: > > Note that before GDB 10 goes out with this new exec-file-mismatch feature, > we should sort out: https://sourceware.org/bugzilla/show_bug.cgi?id=25475 > as possibly fixing this bug might imply to change the options of > 'set exec-file-mismatch' > (see last comment in the bug). Indeed we should. I'll be sending the build ID validation patch to gdb-patches soon. Thanks, Pedro Alves