Re: [RFA] Fix PR gdb/11702, printing of static const member variables

[Doug Evans <dje@google.com>]

On Sun, Jun 27, 2010 at 11:24 AM, Doug Evans <dje@google.com> wrote:
> Hi.
>
> This patch fixes http://sourceware.org/bugzilla/show_bug.cgi?id=11702
>
> [...]
>
> There is one outstanding issue.
> "info var static_const_member" should work, I *think*.
> Is that true?
> If so, then more work needs to be done (or even a different approach,
> but the current patch seems reasonable).
>
> symtab.c:search_symbols has this:
>
>              if (file_matches (real_symtab->filename, files, nfiles)
>                  && ((regexp == NULL
>                       || re_exec (SYMBOL_NATURAL_NAME (sym)) != 0)
>                      && ((kind == VARIABLES_DOMAIN && SYMBOL_CLASS (sym) != LOC_TYPEDEF
>                           && SYMBOL_CLASS (sym) != LOC_UNRESOLVED
>                           && SYMBOL_CLASS (sym) != LOC_BLOCK
>>>>>                       && SYMBOL_CLASS (sym) != LOC_CONST)
>                          || (kind == FUNCTIONS_DOMAIN && SYMBOL_CLASS (sym) == LOC_BLOCK)
>                          || (kind == TYPES_DOMAIN && SYMBOL_CLASS (sym) == LOC_TYPEDEF))))
>
>
> This prevents static const members from being found using the current
> implementation.  Why do we care about LOC_CONST here?
> [And, if we do, this also needs to check LOC_CONST_BYTES ...]

Sigh.
The LOC_CONST here is used to catch enums.
Maybe another symbol table cleanup is to not put enum values in
VARIABLES_DOMAIN.