From: Vladimir Prus <vladimir@codesourcery.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: Better realpath
Date: Sat, 14 Jun 2008 15:10:00 -0000 [thread overview]
Message-ID: <200806141614.07742.vladimir@codesourcery.com> (raw)
In-Reply-To: <umylol0hq.fsf@gnu.org>
On Saturday 14 June 2008 15:28:01 Eli Zaretskii wrote:
> > From: Vladimir Prus <vladimir@codesourcery.com>
> > Date: Sat, 14 Jun 2008 10:24:41 +0400
> >
> > GDB has a function to get real path of a file, gdb_realpath. Unfortunately,
> > that function is essentially a copy-paste of libiberty's lrealpath, with
> > the extra bonus that gdb_realpath *does not* have any Windows-specific
> > code. As result, GDB is not capable to simplify ".." in windows paths,
> > and among other problems, breakpoints set using full file names containing
> > ".." will not work.
> >
> > This patch makes GDB use libibery's lrealpath. OK?
>
> There were past discussions about this; please read them before
> concluding that lrealpath is all we need.
I'm not concluding this, I'm concluding it is strictly better than
gdb_realpath in its current form. And given that currently, trying
to set a breakpoint using full path with ".." plain does not work,
I think the proposed patch is definitely an improvement.
The implications of the current behaviour are much more grave than it
seems. Presently, Eclipse uses file basename to set breakpoints by
default, which obviously breaks badly if there two files with the same
basename in the project, which is not uncommon. And if we try to use
full paths on Windows, we'll immediately hit the current limitations.
So, without gdb changes, breakpoints in Eclipse are half-broken. In
fact, breakpoints in any frontend are half broken on Windows.
> My records seem to indicate
> that a thread Re "fullname attribute for GDB/MI stack frames" in May
> 2005 on this list is one of them, but maybe there were more. You will
> find my critique of what lrealpath does on Windows in a message in
> that thread I sent on May 29, and suggested ways to improve it in a
> followup message on the same day. I think if we are going to use
> lrealpath, we should at least make its behavior consistent and correct
> on all supported platforms, including native Windows (i.e. MinGW).
Speaking of the issues you've raised in:
http://sourceware.org/ml/gdb-patches/2005-05/msg00612.html
I think that:
1. The order of slashes is a cosmetic issue.
2. The case of filenames is also a cosmetic issues.
3. The matter of filename existance is a behaviour issue, and I think
I can modify gdb_realpath to perform a check explicitly. OTOH, it's not
clear if any code actually expects file existane check to be performed.
- Volodya
next prev parent reply other threads:[~2008-06-14 12:14 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-14 11:09 Vladimir Prus
2008-06-14 11:30 ` Pierre Muller
2008-06-14 12:14 ` Vladimir Prus
2008-06-14 14:29 ` Eli Zaretskii
2008-06-14 15:10 ` Vladimir Prus [this message]
2008-06-14 22:05 ` Eli Zaretskii
2008-06-14 22:26 ` Vladimir Prus
2008-06-15 17:37 ` Eli Zaretskii
2008-06-15 17:43 ` Daniel Jacobowitz
2008-06-15 21:04 ` Eli Zaretskii
2008-06-16 3:17 ` Daniel Jacobowitz
2008-06-16 3:32 ` Eli Zaretskii
2008-06-18 18:39 ` Stan Shebs
2008-06-18 20:47 ` DJ Delorie
2008-06-18 15:22 ` Vladimir Prus
2008-06-18 21:08 ` Eli Zaretskii
2008-06-19 7:27 ` Vladimir Prus
2008-06-20 2:49 ` Eli Zaretskii
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=200806141614.07742.vladimir@codesourcery.com \
--to=vladimir@codesourcery.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sources.redhat.com \
/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