From: "Andrew Burgess (Code Review)" <gerrit@gnutoolchain-gerrit.osci.io>
To: gdb-patches@sourceware.org
Cc: Simon Marchi <simon.marchi@polymtl.ca>,
Joel Brobecker <brobecker@adacore.com>
Subject: [review v8] gdb/mi: Add -max-results parameter to some -symbol-info-* commands
Date: Mon, 02 Dec 2019 17:57:00 -0000 [thread overview]
Message-ID: <20191202175740.036EA2816F@gnutoolchain-gerrit.osci.io> (raw)
In-Reply-To: <gerrit.1571909344000.I90a28feb55b388fb46461a096c5db08b6b0bd427@gnutoolchain-gerrit.osci.io>
Andrew Burgess has posted comments on this change.
Change URL: https://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/269
......................................................................
Patch Set 8:
> Patch Set 7:
>
> (8 comments)
>
> I think the way you refactored it is very nice, it breaks the thing up in smaller operations, easier to understand. But it's difficult to figure out what's old stuff and what's new features. Do you think you could split this in separate patches, one that does the refactoring (split in multiple helper methods), that would have no user visible changes, and then the one that adds --max-results?
>
> On the general design of the patch:
>
> If I understand correctly, the --max-results value doesn't bound the expansion of symtabs without one objfile. When we have started to expand the matching symtabs of an objfile, there's no way to stop it unless it has gone through the whole objfile, right? So let's say you do:
>
> -symbol-info-functions --max-results 2 a
>
> we'll still proceed to expand all symtabs of the objfile that have a symbol containing `a`, which may take a very long time. And once that's done, we'll pick the first 2 of all these symbols.
>
> I think it's a reasonable behavior for this patch, it's better to get something working first and incrementally improve.
>
> If we think about how to optimize later: the expand_symtabs_matching method of quick_symbol_functions already takes an "expansion_notify" callback, that is called after each individual symtab expansion. I could see that callback returning a bool, to indicate whether to continue or stop expanding symtabs. We would add the matching symbols from the symtab to our result set in that callback, so we could stop the expansions once we have reached our limit. WDYT?
The problem that worried me most here was the difference between when something needs expanding, and when something is already expanded.
So right now we expand matching symtabs within an objfile, which might do nothing is the symtabs are already expanded, then we rewalk the symtabs and add matching symbols.
If we use the current "just expanded symtab" callback then this only triggers if something gets expanded, if it was already expanded then I don't think we see the callback, so we'd then need to walk all the symtabs again to catch any already expanded symtabs.
This will create strange ordering artifacts where results will appear in a different order the first call vs later calls.
What we really need is a "visit matching symtabs" type function, that applies the same logic as expand, but triggers the callback even for symtabs that are already expanded.
--
Gerrit-Project: binutils-gdb
Gerrit-Branch: master
Gerrit-Change-Id: I90a28feb55b388fb46461a096c5db08b6b0bd427
Gerrit-Change-Number: 269
Gerrit-PatchSet: 8
Gerrit-Owner: Andrew Burgess <andrew.burgess@embecosm.com>
Gerrit-Reviewer: Andrew Burgess <andrew.burgess@embecosm.com>
Gerrit-CC: Joel Brobecker <brobecker@adacore.com>
Gerrit-CC: Simon Marchi <simon.marchi@polymtl.ca>
Gerrit-Comment-Date: Mon, 02 Dec 2019 17:57:39 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
next prev parent reply other threads:[~2019-12-02 17:57 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <gerrit.1571909344000.I90a28feb55b388fb46461a096c5db08b6b0bd427@gnutoolchain-gerrit.osci.io>
2019-11-01 1:35 ` [review v2] " Andrew Burgess (Code Review)
2019-11-22 16:42 ` [review v4] " Andrew Burgess (Code Review)
2019-11-22 17:33 ` [review v5] " Andrew Burgess (Code Review)
2019-11-26 23:26 ` [review v6] " Andrew Burgess (Code Review)
2019-11-26 23:40 ` [review v7] " Andrew Burgess (Code Review)
2019-11-27 5:31 ` Simon Marchi (Code Review)
2019-11-27 14:19 ` [review v8] " Andrew Burgess (Code Review)
2019-11-27 14:21 ` Andrew Burgess (Code Review)
2019-12-02 17:57 ` Andrew Burgess (Code Review) [this message]
2019-12-02 18:40 ` Simon Marchi (Code Review)
2019-12-02 19:15 ` [review v9] " Andrew Burgess (Code Review)
2019-12-02 19:18 ` Andrew Burgess (Code Review)
2019-12-02 19:37 ` Simon Marchi (Code Review)
2019-12-02 23:44 ` [review v10] " Andrew Burgess (Code Review)
2019-12-03 0:00 ` Andrew Burgess (Code Review)
2019-12-03 0:00 ` [review v11] " Andrew Burgess (Code Review)
2019-12-03 4:12 ` Simon Marchi (Code Review)
2019-12-03 10:25 ` [review v12] " Andrew Burgess (Code Review)
2019-12-03 10:56 ` [review v13] " Andrew Burgess (Code Review)
2019-12-03 10:59 ` Andrew Burgess (Code Review)
2019-12-03 16:50 ` Simon Marchi (Code Review)
2019-12-03 21:04 ` [review v14] " Andrew Burgess (Code Review)
2019-12-03 21:07 ` Andrew Burgess (Code Review)
2019-12-03 21:12 ` Simon Marchi (Code Review)
2019-12-04 10:49 ` [pushed] " Sourceware to Gerrit sync (Code Review)
2019-12-04 10:49 ` Sourceware to Gerrit sync (Code Review)
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=20191202175740.036EA2816F@gnutoolchain-gerrit.osci.io \
--to=gerrit@gnutoolchain-gerrit.osci.io \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=gnutoolchain-gerrit@osci.io \
--cc=simon.marchi@polymtl.ca \
/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