This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RFC: getting rid of deprecated_hp_som_som_object_present
- From: Randolph Chung <randolph at tausq dot org>
- To: gdb at sources dot redhat dot com
- Date: Wed, 01 Mar 2006 23:12:00 +0800
- Subject: RFC: getting rid of deprecated_hp_som_som_object_present
Recently on gdb-patches there was some mention of this deprecated flag.
I'd like to get some comments/feedback on how to clean this up....
Here are the parts of gdb that uses this flag:
- symtab.c defines this variable
- hppa-hpux-tdep.c initializes this to 0 for each newly created inferior
it also uses this to help determine if we should use the special hp c++
exception support
- hpread.c sets this variable to 1 if we read a file with HP debug
information
- eval.c uses this to decide to punt if we try to do something with a
pointer to member function, or to apply a bias for a pointer to member
variable
- parse.c has a reference to this in a function named
parse_nested_classes_for_hpacc, but this code apparently is no longer
used anywhere in gdb
- valops.c uses this in value_cast to handle casting things from a
pointer to member function/variable to an int or enum
- c-typeprint.c uses this to print extra info for "sized enums"
- cp-valprint.c uses this in cp_print_class_method to handle class
member functions (I think)
Most of these have to do with how gdb handles c++ methods and member
variables, which makes me think that perhaps we should add some hooks to
the cp-abi layer to handle the type conversion logic. This takes care of
eval.c, valops.c, and maybe cp-valprint.c
I'll have to dig through some cvs history to figure out what we want to
do with the bits in parse.c
hpread.c should probably just set the current auto c++ abi type.
what should we do with c-typeprint.c?
I notice that HP's wdb has better support for some of these cases. If we
were to clean up the above it will be worthwhile to look through wdb and
try to merge in some of the logic there (mostly to deal with member
functions)
Any thoughts? Is this even worth touching/fixing?
randolph