From: Simon Marchi <simark@simark.ca>
To: Tom Tromey <tom@tromey.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] Have partial symbol tables own psymbol vectors
Date: Mon, 31 Aug 2020 17:39:39 -0400 [thread overview]
Message-ID: <b0b5e24e-2ba8-66bd-e826-5b0483d311b2@simark.ca> (raw)
In-Reply-To: <87sgc27nez.fsf@tromey.com>
On 2020-08-31 1:09 p.m., Tom Tromey wrote:
> Tom> It occurred to me today that add_psymbol_to_list could now be a method
> Tom> on partial_symtab. I'm going to make that change and then resubmit.
>
> Here's the updated patch.
>
> Tom
>
> commit ac9fbb7aa1adcbc81cf8f6b9114e84c9193ae512
> Author: Tom Tromey <tom@tromey.com>
> Date: Tue Aug 25 11:12:26 2020 -0600
>
> Have partial symbol tables own psymbol vectors
>
> Currently pointers to all partial symbols are stored in two vectors;
> and then indices into these vectors are stored in each partial_symtab.
>
> This patch changes this so that each partial symtab instead has
> vectors of symbols. add_psymbol_to_list can now be changed into a
> method on partial_symtab as well.
>
> My main motivation for doing this is that I am looking into calling
> sort_pst_symbols in the background. However, I haven't actually
> implemented this yet. (Also this may make it more feasible to also
> sort the static psymbols, though I haven't tried that either.)
>
> Also, though, this lets us remove the "current_global_psymbols"
> vector, because now the callers can simply refer directly to the
> psymtab that they are modifying (formerly this was implicit).
>
> The main drawback of this patch is that it increases the size of
> partial symtab.
Hi Tom,
I don't have a lot of time to look at this right now, but I'm trying to remember how this
all works (notably how things are shared between objfiles).
I think it would be a good time to get rid of the objfile parameter in the add_psymbol
methods. This parameter shouldn't be there if the partial symtabs are really
objfile-independent.
Note that partial_symtab::add_psymbol passes the objfile to add_psymbol_to_bcache, which
only uses it to get the psymtab_storage. is there a way it could get it some other way?
The other use of objfile in partial_symtab::add_psymbol is for stats. I think that could
be easily implemented some other way that doesn't require passing the objfile.
I'll try to take another look later to better understand the patch.
Simon
next prev parent reply other threads:[~2020-08-31 21:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-28 19:33 Tom Tromey
2020-08-30 19:18 ` Tom Tromey
2020-08-31 17:09 ` Tom Tromey
2020-08-31 21:39 ` Simon Marchi [this message]
2020-09-01 14:23 ` Tom Tromey
2020-09-01 14:28 ` Simon Marchi
2020-10-17 22:33 ` Tom Tromey
2020-09-01 13:24 ` Simon Marchi
2020-09-01 14:20 ` Tom Tromey
2020-09-01 14:30 ` Simon Marchi
2020-09-01 14:41 ` Simon Marchi
2020-09-01 17:59 ` Tom Tromey
2020-10-17 20:17 ` 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=b0b5e24e-2ba8-66bd-e826-5b0483d311b2@simark.ca \
--to=simark@simark.ca \
--cc=gdb-patches@sourceware.org \
--cc=tom@tromey.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