Re: substitute-path problem

Daniel Jacobowitz
2007-01-12T03:24:06Z

On Fri, Jan 12, 2007 at 07:21:12AM +0400, Joel Brobecker wrote:
> (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)

Yes, this code is complicated and messy and really way too error prone;
the two cases should be the same. This all ties in with the patch Jan
just posted (which I admit that I read, but could not make heads or
tails out of). We need to make the two cases follow the same code path
or we'll keep breaking one of them.

It turns out find_and_open_source does plenty of other things wrong too
with dirname == NULL. I saw it try to open "$cdir/scratch" (literally)
and also "/home/drow/scratch". Not sure if that's really on purpose...
but the latter and a handy symlink solved my immediate problem :-)

BTW, if you have a chance to improve related things: help set
substitute-path was very unhelpful. It doesn't say what the arguments
should be.

--
Daniel Jacobowitz
CodeSourcery