This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug symtab/16929] New: can't canonicalize a type without knowing the expression block


https://sourceware.org/bugzilla/show_bug.cgi?id=16929

            Bug ID: 16929
           Summary: can't canonicalize a type without knowing the
                    expression block
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: symtab
          Assignee: unassigned at sourceware dot org
          Reporter: dje at google dot com

Careful attention to what gdb is doing to process "ptype char" reveals several
bugs (or at least annoyances plus bug(s)).

Parsing the expression "char" properly uses expression_context_block when
looking up symbol char.  But then when printing the type
expression_context_block is not used (NULL is passed for block to lookup_symbol
by replace_typedefs), so symbol lookup has to look through all static blocks
trying to find a definition of char.

There's no *precise* definition of what "canonicalization" means in the context
of cp_canonicalize_string_full.  At least not any near the vicinity of its
definition.  This makes it hard to reason about the code.

Question: For the case of TYPE_CODE_INT, what can canonicalization do, if
anything?  And if it actually can do something, why doesn't that something get
done when the TYPE_CODE_INT is created?
There's a few calls to print_name_maybe_canonical in c-typeprint.c that don't
make sense to me (e.g. TYPE_CODE_ENUM too).

But the high order bit of this particular bug is that it seems wrong to use
expression_context_block in the first lookup of char (while parsing the
expression) and then not use expression_context_block in the second lookup of
char (while canonicalizing the type).  Maybe(!) we can fix this by not trying
to canonicalize TYPE_CODE_INT, but I'm left wondering if all other calls that
do need to call cp_canonicalize_string_full are errantly not using
expression_context_block.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]