From: Aleksandar Ristovski <ARistovski@qnx.com>
To: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: brobecker@adacore.com, dje@google.com, gdb@sourceware.org,
Ryan Mansfield <RMansfield@qnx.com>
Subject: RE: gdb_realpath: dealing with ./ and ../
Date: Tue, 08 Jan 2008 19:21:00 -0000 [thread overview]
Message-ID: <2F6320727174C448A52CEB63D85D11F40A6A@nova.ott.qnx.com> (raw)
>
> > If we can confirm for sure that "normalize_path" is safe, I think the
> idea
> > is good (please read my comment about normalize_path here:
> > http://sourceware.org/ml/gdb-patches/2008-01/msg00138.html)
> >
> > Example
> > DW_AT_name=../main.cc
> > DW_AT_comp_dir=/foo/bar/obj
> > The Directory Table:
> > ..
> > The File Name Table:$
> > Entry>Dir>~~~~Time>~~~Size>~~~Name$
> > 1>~~~~1>~~~~~~0>~~~~~~0>~~~~~~main.cc$
> >
> > Now we get rid of the comp_dir information (this is what effectively
> > happens):
> >
> > NAME=main.cc
> > DIR=/foo/bar
> >
> > And there is no info about /foo/bar/obj.
> >
> >
> > I would think that this is safe.
>
> Unfortunately it isn't. If /foo/bar/obj is a symlink to /bar/foo/obj,
> then ../main.cc actually refers to /bar/foo/main.cc, and not
> /foo/bar/main.cc. So just "normalizing" names is defenitely unsafe.
>
> The big question here is, whether a compiler will actually set
> DW_AT_comp_dir to /foo/bar/obj in that case. One can argue that the
> compilation directory really is /bar/foo/obj in that case and that
> DW_AT_comp_dir should be set to /bar/foo/obj.
Therefore, this concludes this trail of thoughts and this topic should
probably be considered closed.
Any further discussion related to the issue mentioned at the beginning of
the topic should be continued here:
http://sourceware.org/ml/gdb-patches/2008-01/msg00148.html
next reply other threads:[~2008-01-08 19:21 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-08 19:21 Aleksandar Ristovski [this message]
-- strict thread matches above, loose matches on Subject: below --
2008-01-08 16:12 Aleksandar Ristovski
2008-01-08 16:40 ` Mark Kettenis
2008-01-04 22:09 Aleksandar Ristovski
2008-01-04 20:16 Aleksandar Ristovski
2008-01-04 19:52 Aleksandar Ristovski
2008-01-04 20:30 ` Doug Evans
2008-01-04 17:04 Aleksandar Ristovski
2008-01-04 17:42 ` Daniel Jacobowitz
2008-01-04 18:25 ` Joel Brobecker
2008-01-04 21:40 ` Doug Evans
2008-01-04 21:48 ` Daniel Jacobowitz
2008-01-04 22:23 ` Doug Evans
2008-01-03 18:30 Aleksandar Ristovski
2008-01-04 12:52 ` Daniel Jacobowitz
2008-01-03 17:07 Aleksandar Ristovski
2008-01-03 17:13 ` Daniel Jacobowitz
2008-01-07 14:33 ` Joel Brobecker
2008-01-07 17:00 ` Doug Evans
2008-01-08 5:46 ` Joel Brobecker
2008-01-08 19:54 ` Doug Evans
2008-01-03 16:39 Aleksandar Ristovski
2008-01-03 16:52 ` Daniel Jacobowitz
2008-01-03 15:25 Aleksandar Ristovski
2008-01-03 16:00 ` Daniel Jacobowitz
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=2F6320727174C448A52CEB63D85D11F40A6A@nova.ott.qnx.com \
--to=aristovski@qnx.com \
--cc=RMansfield@qnx.com \
--cc=brobecker@adacore.com \
--cc=dje@google.com \
--cc=gdb@sourceware.org \
--cc=mark.kettenis@xs4all.nl \
/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