From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23172 invoked by alias); 26 Sep 2013 08:47:22 -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 23158 invoked by uid 89); 26 Sep 2013 08:47:22 -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; Thu, 26 Sep 2013 08:47:22 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPAM_SUBJECT autolearn=no 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 r8Q8lIkw031003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Sep 2013 04:47:18 -0400 Received: from host2.jankratochvil.net (ovpn-116-66.ams2.redhat.com [10.36.116.66]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r8Q8lDxN011225 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 26 Sep 2013 04:47:16 -0400 Date: Thu, 26 Sep 2013 08:47:00 -0000 From: Jan Kratochvil To: Doug Evans Cc: gdb-patches@sourceware.org Subject: Re: [RFC] Record objfile->original_name as an absolute path Message-ID: <20130926084713.GA11031@host2.jankratochvil.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2013-09/txt/msg00920.txt.bz2 Hi Doug, On Thu, 26 Sep 2013 03:29:16 +0200, Doug Evans wrote: > The comment for objfile->original_name says the path is stored as an > absolute path, but that's not the case, oops, sorry. > [Later, if we ever choose to display objfile->original_name in > some context, and want to clean up the name a bit (/tmp/./foo -> /tmp/foo), There is pending [patchv2] Improve Executable displayed path (PR 15415 regression kind #2) https://sourceware.org/ml/gdb-patches/2013-09/msg00865.html to fix another filename regression of gdb-7.5 -> gdb-7.6 by me. Then GDB will display really /tmp/foo for the executable name although that is unrelated to objfile->original_name. Therefore the "./" resolving does not seem to be (currently) an issue I think. > I can imagine making a function out of the canonicalizer in > cli-cmds.c:cd_command and using that. > [We wouldn't want to remove "../" for this case though unless we go to > the extra trouble of not expanding symlinks.]] > > 2013-09-25 Doug Evans > > * objfiles.c (allocate_objfile): Save original_name as an absolute > path. > * objfiles.c (struct objfile): Expand comment on original_name. > * utils.c (gdb_abspath): New function. > * utils.h (gdb_abspath): Declare. > > testsuite/ > * gdb.dwarf/dwp-symlink.c: Fake out gdb to not load debug info > at start. > * gdb.dwarf/dwp-symlink.exp: Test trying to load dwp when the binary > has been specified with a relative path and we have chdir'd before > accessing the debug info. > > Index: objfiles.c > =================================================================== > RCS file: /cvs/src/src/gdb/objfiles.c,v > retrieving revision 1.168 > diff -u -p -r1.168 objfiles.c > --- objfiles.c 26 Sep 2013 01:08:35 -0000 1.168 > +++ objfiles.c 26 Sep 2013 01:11:55 -0000 > @@ -270,6 +270,7 @@ struct objfile * > allocate_objfile (bfd *abfd, const char *name, int flags) > { > struct objfile *objfile; > + char *expanded_name; > > objfile = (struct objfile *) xzalloc (sizeof (struct objfile)); > objfile->psymbol_cache = psymbol_bcache_init (); > @@ -283,10 +284,18 @@ allocate_objfile (bfd *abfd, const char > if (name == NULL) > { > gdb_assert (abfd == NULL); > - name = "<>"; > + expanded_name = xstrdup ("<>"); > } > - objfile->original_name = obstack_copy0 (&objfile->objfile_obstack, name, > - strlen (name)); > + else > + expanded_name = gdb_abspath (name); Maybe that gdb_abspath should be rather done by the caller as there is also objfile = allocate_objfile (NULL, "<< JIT compiled code >>", 0); and calling gdb_abspath ("<< JIT compiled code >>") does not seem great. OTOH we could call gdb_abspath() only if abfd != NULL but so far nobody guarantees if abfd == NULL then NAME is not a valid filename. > + objfile->original_name = obstack_copy0 (&objfile->objfile_obstack, > + expanded_name, > + strlen (expanded_name)); > + xfree (expanded_name); > + > + /* Update the per-objfile information that comes from the bfd, ensuring > + that any data that is reference is saved in the per-objfile data > + region. */ > > /* Update the per-objfile information that comes from the bfd, ensuring > that any data that is reference is saved in the per-objfile data > Index: objfiles.h > =================================================================== > RCS file: /cvs/src/src/gdb/objfiles.h,v > retrieving revision 1.112 > diff -u -p -r1.112 objfiles.h > --- objfiles.h 24 Sep 2013 14:00:06 -0000 1.112 > +++ objfiles.h 26 Sep 2013 01:11:55 -0000 > @@ -205,8 +205,10 @@ struct objfile > > struct objfile *next; > > - /* The object file's name, tilde-expanded and absolute. This > - pointer is never NULL. This does not have to be freed; it is > + /* The object file's original name as specified by the user, > + made absolute, and tilde-expanded. However, it is not canonicalized > + (i.e., it has not been passed through gdb_realpath). > + This pointer is never NULL. This does not have to be freed; it is > guaranteed to have a lifetime at least as long as the objfile. */ > > char *original_name; > Index: utils.c > =================================================================== > RCS file: /cvs/src/src/gdb/utils.c,v > retrieving revision 1.306 > diff -u -p -r1.306 utils.c > --- utils.c 13 Aug 2013 08:31:20 -0000 1.306 > +++ utils.c 26 Sep 2013 01:11:55 -0000 > @@ -3204,6 +3204,38 @@ gdb_realpath (const char *filename) > return xstrdup (filename); > } > > +/* Return PATH in absolute form, performing tilde-expansion if necessary. > + PATH cannot be NULL or the empty string. > + This does not resolve symlinks however, use gdb_realpath for that. > + Space for the result is allocated with malloc. > + If the path is already absolute, it is strdup'd. > + If there is a problem computing the absolute path, the path is returned > + unchanged (still strdup'd). */ > + > +char * > +gdb_abspath (const char *path) > +{ > +#if defined (PATH_MAX) > + char cwd_buf[PATH_MAX]; > +#elif defined (_WIN32) > + char cwd_buf[MAX_PATH]; > +#else > + char cwd_buf[1024]; > +#endif > + > + gdb_assert (path != NULL && path[0] != '\0'); > + > + if (path[0] == '~') > + return tilde_expand (path); > + > + if (IS_ABSOLUTE_PATH (path)) > + return xstrdup (path); > + > + if (getcwd (cwd_buf, sizeof (cwd_buf)) == NULL) > + return xstrdup (path); > + return concat (cwd_buf, SLASH_STRING, path, NULL); It should be integrated with the tail of openp() where is a check for: /* Beware the // my son, the Emacs barfs, the botch that catch... */ It also uses global 'current_directory' variable. > +} > + > ULONGEST > align_up (ULONGEST v, int n) > { [...] Thanks, Jan