Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: gdb@sourceware.org
Subject: Re: substitute-path problem
Date: Fri, 12 Jan 2007 03:20:00 -0000	[thread overview]
Message-ID: <20070112032112.GO23012@adacore.com> (raw)
In-Reply-To: <20070112025149.GA7621@nevyn.them.org>

[-- Attachment #1: Type: text/plain, Size: 1189 bytes --]

> I suspect compiling the file with a full path on the gcc command line
> would reproduce this.  Do you think we're applying the substitution
> rule in the wrong place?

I can indeed reproduce. I think that we are just missing one case.
First we try the fullpath if we already know it. Then the dirname
if we have it. But if there is no dirname, then we should try the
filename. Chances are, if the dirname is not specified, the file path
is embedded in the filename.

I will test the attach patch and commit if all is fine. In the meantim,
that might help you out in your work.

(I have wondered many times how much easier it would be for us if
we resolved the filename+dirname into a fullpath name at debug info
reading time, and then only stored that in our data structures - not
sure if it is posssible, but if it is, we would be able to assume in
the rest of the code that symbol->filename is always a fullpath, or
the closest to it we can do based on the information the compiler provided.
But I think that would change the behavior of certain things like source
file search with the dir path. I'm not completely sure yet, I would have
to spend some time researching this)

-- 
Joel

[-- Attachment #2: subst.diff --]
[-- Type: text/plain, Size: 753 bytes --]

Index: source.c
===================================================================
RCS file: /cvs/src/src/gdb/source.c,v
retrieving revision 1.76
diff -u -p -r1.76 source.c
--- source.c	8 Aug 2006 22:06:06 -0000	1.76
+++ source.c	12 Jan 2007 03:15:55 -0000
@@ -1001,6 +1001,16 @@ find_and_open_source (struct objfile *ob
 	  strcat (path + len, source_path + len + cdir_len);	/* After $cdir */
 	}
     }
+  else
+    {
+      char *rewritten_filename = rewrite_source_path (filename);
+
+      if (rewritten_filename != NULL)
+        {
+          make_cleanup (xfree, rewritten_filename);
+          filename = rewritten_filename;
+        }
+    }
 
   result = openp (path, OPF_SEARCH_IN_PATH, filename, OPEN_MODE, 0, fullname);
   if (result < 0)

  reply	other threads:[~2007-01-12  3:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-12  2:51 Daniel Jacobowitz
2007-01-12  3:20 ` Joel Brobecker [this message]
2007-01-12  3:22   ` Joel Brobecker
2007-01-12  3:24   ` Daniel Jacobowitz
2007-01-12  3:29     ` Joel Brobecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070112032112.GO23012@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox