From: Daniel Jacobowitz <drow@false.org>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb@sourceware.org
Subject: Re: substitute-path problem
Date: Fri, 12 Jan 2007 03:24:00 -0000 [thread overview]
Message-ID: <20070112032356.GA8983@nevyn.them.org> (raw)
In-Reply-To: <20070112032112.GO23012@adacore.com>
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
next prev parent reply other threads:[~2007-01-12 3:24 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
2007-01-12 3:22 ` Joel Brobecker
2007-01-12 3:24 ` Daniel Jacobowitz [this message]
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=20070112032356.GA8983@nevyn.them.org \
--to=drow@false.org \
--cc=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