From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5046 invoked by alias); 4 Sep 2013 16:55:36 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 5037 invoked by uid 89); 4 Sep 2013 16:55:35 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 04 Sep 2013 16:55:35 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.8 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r84GtVI3032309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Sep 2013 12:55:31 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r84GtTkE030781; Wed, 4 Sep 2013 12:55:30 -0400 Message-ID: <52276600.7010706@redhat.com> Date: Wed, 04 Sep 2013 16:55:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Doug Evans CC: Jan Kratochvil , gdb-patches Subject: Re: [commit+7.6.1] [patch] [7.6.1] Fix argv[0] symlink regression (PR 15415) References: <20130826182111.GA19509@host2.jankratochvil.net> <21019.47767.404597.352962@ruffy.mtv.corp.google.com> <20130827140915.GA17861@host2.jankratochvil.net> <21022.10862.436924.879667@ruffy.mtv.corp.google.com> <20130828180359.GB4770@host2.jankratochvil.net> <52271009.50805@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-09/txt/msg00138.txt.bz2 On 09/04/2013 05:31 PM, Doug Evans wrote: > On Wed, Sep 4, 2013 at 3:48 AM, Pedro Alves wrote: >> It seems this patch introduces some output inconsistency >> (only tried mainline): >> >> $ ./gdb >> ... >> (gdb) file ./gdb >> Reading symbols from /home/pedro/gdb/mygit/build/gdb/gdb...done. >> Setting up the environment for debugging gdb. >> (top-gdb) info inferiors >> Num Description Executable >> * 1 /home/pedro/gdb/mygit/build/gdb/./gdb >> (top-gdb) >> >> Note "gdb/gdb" vs "gdb/./gdb". >> >> (top-gdb) file gdbserver/../gdb >> Load new symbol table from "/home/pedro/gdb/mygit/build/gdb/gdb"? (y or n) y >> Reading symbols from /home/pedro/gdb/mygit/build/gdb/gdb...done. >> (top-gdb) info inferiors >> Num Description Executable >> * 1 /home/pedro/gdb/mygit/build/gdb/gdbserver/../gdb >> (top-gdb) >> >> Note ".../gdb/gdb" vs ".../gdb/gdbserver/../gdb". >> >> I tried your new series at >> , and >> seems there's still some inconsistency: >> >> (gdb) file ./gdb >> Reading symbols from /home/pedro/gdb/mygit/build/gdb/./gdb...done. >> Setting up the environment for debugging gdb. >> (top-gdb) info inferiors >> Num Description Executable >> * 1 /home/pedro/gdb/mygit/build/gdb/./gdb >> (top-gdb) info files >> Symbols from "/home/pedro/gdb/mygit/build/gdb/./gdb". >> Local exec file: >> `/home/pedro/gdb/mygit/build/gdb/./gdb', file type elf64-x86-64. >> >> This one's consistent now, but then this one's odd: >> >> (top-gdb) file gdbserver/../gdb >> Load new symbol table from "/home/pedro/gdb/mygit/build/gdb/./gdb"? (y or n) y >> Reading symbols from /home/pedro/gdb/mygit/build/gdb/./gdb...done. >> >> (top-gdb) info inferiors >> Num Description Executable >> * 1 /home/pedro/gdb/mygit/build/gdb/gdbserver/../gdb >> (top-gdb) >> >> Hmm. It seems to only happen after having loaded "./gdb" first. This >> sounds like related to the filename handling in the gdb/bfd cache? GDB >> finds reuses the same bfd (as gdbserver/../gdb is the same file as >> the previous ./gdb), and then we printing the filename that had >> been associated with the bfd before, instead of the one that was >> specified in the second "file" ? > > Hi. Some random thoughts. > > If the user wants to debug foo/bar/../baz, I don't mind gdb printing > it as foo/bar/../baz. > Other's might of course. I don't mind either. Opening foo/bar/../baz is not the same as opening foo/baz, if bar is a symlink. That's not usually true when talking about "cd", though. Maybe what we'll find out we need in the future is a knob users can turn on to say "also print me the realpath in addition if it differs from what I specified". > > Removing ./ from paths is easy and reasonable enough. Yeah, I think we should. > > If gdb is debugging a new file I would have expected the old file to > be gone from bfd's cache. Well, or not, a valid caching policy may be to monitor memory/resource usage, and as long as resources are available, assume the same file will be reopened soon. I don't really know the policy here though, it may just be the original file is only closed after the new one is opened. But, the issue should trigger even if not closing the old file. Let me check... (gdb) add-inferior -exec ./gdbserver/../gdb Added inferior 2 Reading symbols from /home/pedro/gdb/mygit/build/gdb/./gdbserver/../gdb...done. Setting up the environment for debugging gdb. (top-gdb) add-inferior -exec ./gdb Added inferior 3 Reading symbols from /home/pedro/gdb/mygit/build/gdb/./gdbserver/../gdb...done. (top-gdb) info inferiors Num Description Executable 3 /home/pedro/gdb/mygit/build/gdb/./gdb 2 /home/pedro/gdb/mygit/build/gdb/./gdbserver/../gdb * 1 Note it shows "gdbserver/../gdb" for inferior 3 too. vs (new run from scratch): (gdb) add-inferior -exec ./gdb Added inferior 2 Reading symbols from /home/pedro/gdb/mygit/build/gdb/./gdb...done. Setting up the environment for debugging gdb. (top-gdb) add-inferior -exec ./gdbserver/../gdb Added inferior 3 Reading symbols from /home/pedro/gdb/mygit/build/gdb/./gdb...done. Setting up the environment for debugging gdb. (top-gdb) info inferiors Num Description Executable 3 /home/pedro/gdb/mygit/build/gdb/./gdbserver/../gdb 2 /home/pedro/gdb/mygit/build/gdb/./gdb * 1 Note it shows "./gdb" for inferior 2 too. > [The problem may be in the sequencing.] Yep, whatever is used first is reused. > We do need to be consistent with which flavor of a path we use. -- Pedro Alves