From: "André Pönitz" <apoenitz@t-online.de>
To: Simon Marchi <simark@simark.ca>
Cc: Andrew Burgess <andrew.burgess@embecosm.com>,
gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH 3/3] gdb/mi: Add new commands -symbol-info-{functions,variables,types}
Date: Fri, 04 Oct 2019 13:46:00 -0000 [thread overview]
Message-ID: <20191004134845.GA1528@klara> (raw)
In-Reply-To: <32bedef4-727e-ad35-318b-8ebc18924583@simark.ca>
On Thu, Oct 03, 2019 at 11:01:12PM -0400, Simon Marchi wrote:
> On 2019-09-26 7:09 p.m., Andrew Burgess wrote:
> > Add new MI commands -symbol-info-functions, -symbol-info-variables,
> > and -symbol-info-types which correspond to the CLI commands 'info
> > functions', 'info variables', and 'info types' respectively.
>
> Hi Andrew,
>
> The first thing I tried was to run it on GDB itself and run "-symbol-info-functions"
> by itself. Apparently, it tries to list all functions in the program :). I think
> we need to be careful with that, as it would be really easy for a debug session to
> become unresponsive. Imagine an IDE that has a little box to search symbols by name.
> The user while debugging a big program, types "e<enter>", which generates this
> MI command:
>
> -symbol-info-functions --name "e"
>
> This would essentially hang the debug session while GDB expands all the symtabs with
> at least a function with "e" in its name. It would take a huge amount of time and
> memory. I don't know how easy it would be to implement, but for these cases, a
> "--max-results N" switch, which would stop the search early, might useful.
From an (one...) IDE's point of view, any such limit setting would be desirable,
and I'd personally would appreciate some limit on time, with the result record
indication on whether the result is complete or the timeout was hit.
> [...]
>
> Also, since this output is meant to be consumed by a front-end, it would be
> interesting to have the details of the symbols in separate fields. For example,
> for variables, have the type and name in separate fields. This gives front-ends
> more freedom on how to display them.
Indeed.
Andre'
next prev parent reply other threads:[~2019-10-04 13:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-26 23:09 [PATCH 0/3] New MI commands for info functions/types/variables Andrew Burgess
2019-09-26 23:09 ` [PATCH 3/3] gdb/mi: Add new commands -symbol-info-{functions,variables,types} Andrew Burgess
2019-09-27 5:43 ` Eli Zaretskii
2019-10-04 3:01 ` Simon Marchi
2019-10-04 13:46 ` André Pönitz [this message]
2019-10-11 12:32 ` Andrew Burgess
2019-09-26 23:09 ` [PATCH 1/3] gdb: Don't print a newline in language la_print_typedef methods Andrew Burgess
2019-09-26 23:09 ` [PATCH 2/3] gdb: Split print_symbol_info into two parts Andrew Burgess
2019-10-04 1:50 ` Simon Marchi
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=20191004134845.GA1528@klara \
--to=apoenitz@t-online.de \
--cc=andrew.burgess@embecosm.com \
--cc=gdb-patches@sourceware.org \
--cc=simark@simark.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