This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Why are DW_TAG_{typedef,base_type,subrange_type} in static symbol list?
- From: dje at google dot com (Doug Evans)
- To: gdb at sourceware dot org
- Date: Thu, 17 Nov 2011 10:47:56 -0800 (PST)
- Subject: Why are DW_TAG_{typedef,base_type,subrange_type} in static symbol list?
Hi.
Does anyone understand why this code in dwarf2read.c adds typedefs,
base_type, subrange_type to objfile->static_psymbols and not
objfile->global_psymbols?
At least for c++ wouldn't a better location be global_psymbols?
[Similarly to how DW_TAG_{class,structure,...} types are handled?]
add_partial_symbol:
case DW_TAG_typedef:
case DW_TAG_base_type:
case DW_TAG_subrange_type:
add_psymbol_to_list (actual_name, strlen (actual_name),
built_actual_name,
VAR_DOMAIN, LOC_TYPEDEF,
&objfile->static_psymbols,
0, (CORE_ADDR) 0, cu->language, objfile);
break;
vs:
case DW_TAG_class_type:
[...]
add_psymbol_to_list (actual_name, strlen (actual_name),
built_actual_name,
STRUCT_DOMAIN, LOC_TYPEDEF,
(cu->language == language_cplus
|| cu->language == language_java)
? &objfile->global_psymbols
: &objfile->static_psymbols,
0, (CORE_ADDR) 0, cu->language, objfile);
And similarly in new_symbol_full:
[these two cases should at least be combined]
case DW_TAG_typedef:
SYMBOL_CLASS (sym) = LOC_TYPEDEF;
SYMBOL_DOMAIN (sym) = VAR_DOMAIN;
list_to_add = cu->list_in_scope;
break;
case DW_TAG_base_type:
case DW_TAG_subrange_type:
SYMBOL_CLASS (sym) = LOC_TYPEDEF;
SYMBOL_DOMAIN (sym) = VAR_DOMAIN;
list_to_add = cu->list_in_scope;
break;
vs:
case DW_TAG_class_type:
[...]
list_to_add = (cu->list_in_scope == &file_symbols
&& (cu->language == language_cplus
|| cu->language == language_java)
? &global_symbols : cu->list_in_scope);