Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [3/10] introduce psymtab users
Date: Thu, 26 Apr 2012 18:42:00 -0000	[thread overview]
Message-ID: <87zk9y72zv.fsf@fleche.redhat.com> (raw)
In-Reply-To: <20120426172711.GA19350@host2.jankratochvil.net> (Jan	Kratochvil's message of "Thu, 26 Apr 2012 19:27:11 +0200")

>> +  /* A flag that is temporarily used when searching psymtabs.  */
>> +
>> +  unsigned char searched_flag;

Jan> Please make it the enum.

I didn't do this originally because this field and the enum values are
purely temporary.  They have no meaning outside one little bit of the
code.

But, I don't mind, I will make the change.  Very little should be
including psympriv.h anyway.

>> @@ -760,6 +769,11 @@ lookup_partial_symbol (struct partial_symtab
>> *pst, const char *name,
>> static struct symtab *
>> psymtab_to_symtab (struct partial_symtab *pst)
>> {
>> +  /* If it is a shared psymtab, find an unshared psymtab that includes
>> +     it.  Any such psymtab will do.  */
>> +  while (pst->users != NULL)
>> +    pst = pst->users[0];

Jan> Currently GDB already has a problem that if it needs to expand
Jan> symtab A to get symbol X it already expands also symtabs B, C and
Jan> D, all of them pretty big for C++.

Jan> With such random choosing of a symtab for expansion this multi-expand
Jan> performance hit may get even worse for big C++ programs.

Jan> (Not sure if you do not already plan some more general fix for that.)

Someday I would like to implement my lazy CU expansion ideas.
Well, unless we think of something better.  And if we think they'll help
enough; first one of us should redo the performance comparisons.

In the short term, though, I don't think this makes things any worse.
My reasoning is that in the uncompressed DWARF, gdb would read the first
matching CU.  With the compressed DWARF, gdb still does exactly this,
only it reads the CU and the included PUs.

Jan> I do not see why to use the 'keep_going' variable here, just use 'break;'.

Jan> But it applies also to the current code.

Yeah, I don't want to change code I just moved around.
Cleanups are fine separately.

Tom


  reply	other threads:[~2012-04-26 18:38 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-25 18:26 Tom Tromey
2012-04-26 18:01 ` Jan Kratochvil
2012-04-26 18:42   ` Tom Tromey [this message]
2012-04-26 18:48     ` Jan Kratochvil
2012-04-26 19:04       ` Tom Tromey
2012-04-27 10:14 ` Jan Kratochvil
2012-04-30 18:52 ` Doug Evans
2012-04-30 21:43   ` Doug Evans
2012-05-10 19:52 ` Tom Tromey

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=87zk9y72zv.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@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