Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: Francois Rigault <francois.rigault@amadeus.com>
Cc: gdb-patches@sourceware.org, Daniel Jacobowitz <drow@false.org>,
	        Joel Brobecker <brobecker@gmail.com>
Subject: Re: [Patch] Improve path lookup of absolute source file
Date: Fri, 24 Apr 2009 14:52:00 -0000	[thread overview]
Message-ID: <m3prf2nly6.fsf@fleche.redhat.com> (raw)
In-Reply-To: <OF25118363.80891CC6-ONC125757C.004D2845-C125757C.0050587D@amadeus.com> (Francois Rigault's message of "Tue\, 17 Mar 2009 15\:37\:33 +0100")

>>>>> "Francois" == Francois Rigault <francois.rigault@amadeus.com> writes:

This particular problem has 3 pending patches... the one from this
thread, and also:

http://sourceware.org/ml/gdb-patches/2008-06/msg00027.html
http://sourceware.org/ml/gdb-patches/2009-01/msg00325.html

Of these I prefer the approach taken by the patch I'm replying to,
because it solves the symlink problem.  The first patch also changes
lookup_symtab, so I'm not sure whether the patch I'm responding to is
sufficient.

Francois> In the patch below, the file name lookup is done in 2 times :
Francois> The first pass will try to resolve the file name only if basenames 
Francois> match. The second pass will try to resolve the file name as before,
Francois> resolving all the files path from the symtab.

This sounds reasonable to me.  It may change the order in which files
are found, but I don't think we provide any guarantees about that.


Do you have a copyright assignment on file?  This patch is big enough
to require one.

The patch itself looks reasonable, though it has a number of
formatting nits to pick.  We can work these out once the paperwork
issue is dealt with.

Alternatively, if one of the other patch submitters wants to rewrite
his patch to take the 2-pass approach, that would be fine too.

It seems to me that the 2-pass approach means that a typo in the
command will still make gdb pause for a long time while it searches
all the psymtabs (and fails).  Perhaps the loop needs a QUIT?  I don't
know if that is safe here or not, though the calls to make_cleanup
make me think that is probably is.

Tom


  reply	other threads:[~2009-04-24 14:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-11 10:32 Francois Rigault
2009-03-15 19:44 ` Joel Brobecker
2009-03-17 15:57   ` Francois Rigault
2009-04-24 14:52     ` Tom Tromey [this message]
2009-04-24 15:12       ` Eli Zaretskii
  -- strict thread matches above, loose matches on Subject: below --
2009-07-15 17:16 Francois Rigault
2009-07-30  0:07 ` Tom Tromey
2008-09-11 12:48 Francois Rigault
2008-09-26  4:15 ` Thiago Jung Bauermann
2008-09-26 13:02 ` 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=m3prf2nly6.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=brobecker@gmail.com \
    --cc=drow@false.org \
    --cc=francois.rigault@amadeus.com \
    --cc=gdb-patches@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