Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Doug Evans <dje@google.com>
Cc: Keith Seitz <keiths@redhat.com>,
	Joel Brobecker <brobecker@adacore.com>,
	       psmith@gnu.org, gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [patch] Improve symbol lookup performance noted in PR 15519
Date: Thu, 06 Jun 2013 10:18:00 -0000	[thread overview]
Message-ID: <51B06201.7010507@redhat.com> (raw)
In-Reply-To: <CADPb22TJyzLsoKn581GdmqybSaNtVS-tpXiUvuwVcmzKK0_nYw@mail.gmail.com>

On 06/05/2013 11:31 PM, Doug Evans wrote:
> On Mon, Jun 3, 2013 at 10:27 AM, Pedro Alves <palves@redhat.com> wrote:
>> > Just to make sure I understand the change -- I see
>> > cp_lookup_symbol_namespace does:
...
>> > and a chunk of the speedup comes from skipping that, correct?
>> > That is, it is supposedly unnecessary to look symbol imports
>> > when looking up a symbol in a baseclass, right?
> Right.
> There are two kinds of "using"s: directives and declarations.
> "using directives" cannot appear in class scope, and that is what
> cp_lookup_symbol_namespace handles.
> And, AFAICT, gdb doesn't support "using declarations" yet,
> which does affect base class lookup here.
> 
>> > The patch then also replaces a lookup_symbol_static with a specific
>> > block call followed by a fallback lookup_static_symbol_aux search over all
>> > objfiles, by always doing the lookup_static_symbol_aux search over
>> > all objfiles.  It makes me wonder if it was there for a reason things were
>> > done that way before, like for something like the same named class/methods
>> > being implemented/hidden/private in different sos/dlls (therefore not
>> > really subject to ODR), therefore making it desirable to lookup in the
>> > same context first.  I have no idea, probably not.  :-)  I guess I'm just
>> > after getting the analysis/conclusion that led to the change
>> > recorded for posterity.  :-)
> It's kind of a toss up.
> Even if someone played games with visibility the previous lookup only
> checks the current symtab; there's no guarantee the needed debug info
> isn't in another symtab in that objfile (e.g., due to gcc's aggressive
> debug info pruning).
> Ultimately, I think what we want is to search the current objfile, and
> then search the remaining objfiles, but I left that for another day.
> Still, searching the current symtab isn't expensive enough that
> re-searching it is a problem and it sometimes will win.
> So I've modified the patch to keep that behaviour.
> Still have to search the world if block != NULL though.  Improving
> that's also left for another day.

Thanks.  While at it, a couple comments:

>  # Check inheritance of typedefs.
> -foreach klass {"A" "D" "E" "F"} {
> +foreach klass {"A" "D" "E" "F" "A2" "D2"} {
>      gdb_test "ptype ${klass}::value_type" "type = int"
>      gdb_test "whatis ${klass}::value_type" "type = int"
>      gdb_test "p (${klass}::value_type) 0" " = 0"
> @@ -57,6 +58,13 @@ if ![runto 'marker1'] then {
>      continue
>  }
>  
> +# Check inheritance of typedefs again, but this time with an active block.
> +foreach klass {"A" "D" "A2" "D2"} {
> +    gdb_test "ptype ${klass}::value_type" "type = int"
> +    gdb_test "whatis ${klass}::value_type" "type = int"
> +    gdb_test "p (${klass}::value_type) 0" " = 0"
> +}
> +

Looks like this will create duplicate messages in gdb.sum.
Could you use with_test_prefix to make them unique please?

>  gdb_test "up" ".*main.*" "up from marker1"
>  
>  # Print class types and values.
> Index: testsuite/gdb.cp/derivation2.cc
> ===================================================================
> RCS file: testsuite/gdb.cp/derivation2.cc
> diff -N testsuite/gdb.cp/derivation2.cc
> --- /dev/null	1 Jan 1970 00:00:00 -0000
> +++ testsuite/gdb.cp/derivation2.cc	5 Jun 2013 22:21:18 -0000
> @@ -0,0 +1,49 @@
...
> +   You should have received a copy of the GNU General Public License
> +   along with this program.  If not, see <http://www.gnu.org/licenses/>.
> +   */

(this placement for */ looks a little odd.)

-- 
Pedro Alves


  reply	other threads:[~2013-06-06 10:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-30 23:27 Doug Evans
2013-05-31  3:42 ` Joel Brobecker
2013-05-31  9:40 ` Pedro Alves
2013-05-31 22:33   ` Doug Evans
2013-06-03  6:01     ` Joel Brobecker
2013-06-03 17:27     ` Pedro Alves
2013-06-05 22:31       ` Doug Evans
2013-06-06 10:18         ` Pedro Alves [this message]
2013-06-06 19:03           ` Doug Evans
2013-06-07 14:50             ` Fix formating in copyright headers. (was: Re: [patch] Improve symbol lookup performance noted in PR 15519) Pedro Alves

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=51B06201.7010507@redhat.com \
    --to=palves@redhat.com \
    --cc=brobecker@adacore.com \
    --cc=dje@google.com \
    --cc=gdb-patches@sourceware.org \
    --cc=keiths@redhat.com \
    --cc=psmith@gnu.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