From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17953 invoked by alias); 4 Sep 2013 19:13:15 -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 17941 invoked by uid 89); 4 Sep 2013 19:13:14 -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 19:13:14 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r84JDAv5026851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Sep 2013 15:13:10 -0400 Received: from host2.jankratochvil.net (ovpn-116-29.ams2.redhat.com [10.36.116.29]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r84JD6r1026059 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Sep 2013 15:13:09 -0400 Date: Wed, 04 Sep 2013 19:13:00 -0000 From: Jan Kratochvil To: Pedro Alves Cc: Doug Evans , gdb-patches@sourceware.org Subject: Re: [commit+7.6.1] [patch] [7.6.1] Fix argv[0] symlink regression (PR 15415) Message-ID: <20130904191306.GB22458@host2.jankratochvil.net> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52271009.50805@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2013-09/txt/msg00142.txt.bz2 On Wed, 04 Sep 2013 12:48:41 +0200, 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". That is correct, you have specified different "file" parameter, therefore those inferiors will be executed with different argv[0]. Just the name is displayed in absolute form (with CWD prepended) - argv[0] will be supplied exactly as given by the user (relatively in your case). The other possibility would be to really display argv[0]: * 1 ./gdb + * 1 gdbserver/../gdb But I think the current output above is preferred. > I tried your new series at > , and > seems there's still some inconsistency: I have found the series does not make much sense, going to rework it first. When bfd->filename no longer contains the canonical form then we could use it as its original filename, couldn't we? No, we can't because it can be shared from cache so it may be original filename of an unrelated file. As long as bfd's are shared (based on their canonical name) it does not make sense to put to bfd->filename anything besides the canonical name. But I think objfile->name can store the original (non-canonical) filename. exec_bfd does not have its objfile - it has symfile_objfile which does not have to be equal and argv[0] should IMO correspond rather to exec_bfd than to correspond to symfile_objfile. But we have already exec_filename for exec_bfd so that is no longer a problem. Going to code new series how it will work, thanks for the feedback. In reality xfullpath() (canonical directories, filename intact) was a perfect match as it resolved all relative references to directories while it kept argv[0] in original form (as inferiors generally care only about filename in argv[0] and not about directories in argv[0]; except for GDB relocatability although there it does not matter if the path is canonicalized or not). Just so far I still do not think it is worth it reintroducing xfullpath. Jan