From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23787 invoked by alias); 11 Sep 2002 19:30:39 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 23778 invoked from network); 11 Sep 2002 19:30:38 -0000 Received: from unknown (HELO valrhona.uglyboxes.com) (64.1.192.220) by sources.redhat.com with SMTP; 11 Sep 2002 19:30:38 -0000 Received: from localhost.localdomain (IDENT:QuZlwNtFaPwZdFl9GMIY/cQ3qdwcHK+D@localhost.localdomain [127.0.0.1]) by valrhona.uglyboxes.com (8.11.6/8.11.6) with ESMTP id g8BJXKK04656; Wed, 11 Sep 2002 12:33:21 -0700 Date: Wed, 11 Sep 2002 12:30:00 -0000 From: Keith Seitz X-X-Sender: keiths@valrhona.uglyboxes.com To: Jelmer Vernooij cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] -symbol-info-symbol and -symbol-list-functions In-Reply-To: <20020911191204.GA24463@vernstok.dyndns.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-09/txt/msg00187.txt.bz2 Just a quick comment or two... On Wed, 11 Sep 2002, Jelmer Vernooij wrote: > It's not meant to be committed already, but I'm just wondering whether > I'm using the correct functions, coding style and output. Should I > really use search_symbols for these kinds of things? It seems a little > inefficient to use a function that does regex matching when supplying > a 'normal' symbol name (and it might have some issues as well with > names that contain special regex characters). Why not allow regexp matching? It is much more useful than looking for an exact string. If the UI really wants an exact string match, it's easy enough for it to construct a regexp which will do this. + if (p->msymbol == NULL) + { + ui_out_field_string (uiout, "file", p->symtab->filename); + ui_out_field_int (uiout, "line", p->symbol->line); + ui_out_field_string (uiout, "name", p->symbol->ginfo.name); + } + else + { + ui_out_field_string (uiout, "name", p->msymbol->ginfo.name); + } Does this work on an executable with no debug info? With Insight, this code is a lot more complicated... (In other words, couldn't any of these strings be NULL?) Also, as I recall there are accessors for at least ginfo.name (SYMBOL_SOURCE_NAME). Also as I recall, this macro wasn't enough for C++. We modified it a little in insight, too, since SYMBOL_SOURCE_NAME could output mangled names, depending on user setting. We chose to override this: /* A convenience macro for getting the demangled source names, regardless of the user's mangling style. */ #define GDBTK_SYMBOL_SOURCE_NAME(symbol) \ (SYMBOL_DEMANGLED_NAME (symbol) != NULL \ ? SYMBOL_DEMANGLED_NAME (symbol) \ : SYMBOL_NAME (symbol)) +enum mi_cmd_result +mi_cmd_symbol_list_functions (char *command, char **argv, int argc) +{ + struct symbol_search *matches; + if (argc != 0) + error ("mi_cmd_symbol_list_functions doesn't require any arguments"); Why not allow an optional regexp argument to search for, just like the command line? (It could be "" by default, thus listing all functions.) + search_symbols (NULL, FUNCTIONS_NAMESPACE, 0, NULL, &matches); The results of this function need to be deallocated. Suggest adding make_cleanup_free_search_symbols and do_cleanups whenever search_symbols is called. For a working reference of a generic use of search_symbols, see gdb/gdbtk/generic/gdbtk-cmds.c (gdb_search) in the insight module. (You can get this by checking out the file 'src/gdb/gdbtk/generic/gdbtk-cmds.c' from sources.redhat.com.) Keith