RFC: getting rid of deprecated_hp_som_som_object_present

RFC: getting rid of deprecated_hp_som_som_object_present

[Randolph Chung]

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

Re: RFC: getting rid of deprecated_hp_som_som_object_present

[Jim Blandy]

On 3/1/06, Randolph Chung <randolph@tausq.org> wrote:
> Any thoughts? Is this even worth touching/fixing?

"Worth"?  I'm always tempted to assess the "worth" of a project by how
ugly what it would fix is... :)  I think that global variable is
really terrible.  And as the Modula-2 example showed, the change is
getting propagated around.

Given that C99 specifies that enum values are ints, would it make
sense to always print enum values specially if the the enum type's
size is not equal to that of builtin_type_int?

Is anyone using the HP compilers on PA-RISC with FSF GDB?

[Daniel Jacobowitz]

On Wed, Mar 01, 2006 at 11:12:00PM +0800, Randolph Chung wrote:
> 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 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?

Some of it certainly is worth fixing.

I have a question, though, which I think I've asked before.  GCC on
HP/UX uses stabs, so only requires basic SOM support from GDB.  That
should be in decent shape still.  But the stuff read by hpread.c is
only generated by the HP compilers (cc and aCC).

- Are these compilers still important for C?
- Are these compilers still important for C++?

I have not heard from any users of the FSF GDB with the HP compilers in
a long time; for HP-specific features, I suspect more people use HP's
WDB fork of GDB.  If no one is using the HP support, I would like to
remove it from the next release of GDB.

The symbol reader (in hpread.c) is in dubious shape. It worked the last
time Michael Chastain ran it through testing - but that was a few
releases ago and I haven't heard of any substantial uses of it
since.  I've tried to make mechanical changes and interface cleanups
to GDB's symbol readers in the past and gotten stuck up on this one,
which is very hard for me to test.  I could modernize it, but it would
be a substantial (many weeks) time sink.  I don't want to do that if
no one is using it!

There's also a lot of C++ hooks floating around in GDB for the aCC
ABI, and I'm sure many of them don't do what was intended anymore.
And the deprecated global variable Randolph was looking at is scattered
around.

Note, none of this applies to HP's compilers on IA64-HP/UX if that port
is eventually supported in GDB.  They use ELF and the Itanium C++ ABI,
just like GCC.  I believe they also use DWARF-2/DWARF-3.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Is anyone using the HP compilers on PA-RISC with FSF GDB?

[Albert Chin]

On Tue, Aug 01, 2006 at 10:55:30PM -0400, Daniel Jacobowitz wrote:
> 
> I have a question, though, which I think I've asked before.  GCC on
> HP/UX uses stabs, so only requires basic SOM support from GDB.  That
> should be in decent shape still.  But the stuff read by hpread.c is
> only generated by the HP compilers (cc and aCC).
> 
> - Are these compilers still important for C?
> - Are these compilers still important for C++?

We use them to build most of the free software we provide for our
customers.

> I have not heard from any users of the FSF GDB with the HP compilers in
> a long time; for HP-specific features, I suspect more people use HP's
> WDB fork of GDB.  If no one is using the HP support, I would like to
> remove it from the next release of GDB.

We ship GDB for all platforms except HP-UX, where we ship HP's WDB.

-- 
albert chin (china@thewrittenword.com)

Re: Is anyone using the HP compilers on PA-RISC with FSF GDB?

[Daniel Jacobowitz]

On Fri, Aug 04, 2006 at 12:00:24AM -0500, Albert Chin wrote:
> On Tue, Aug 01, 2006 at 10:55:30PM -0400, Daniel Jacobowitz wrote:
> > 
> > I have a question, though, which I think I've asked before.  GCC on
> > HP/UX uses stabs, so only requires basic SOM support from GDB.  That
> > should be in decent shape still.  But the stuff read by hpread.c is
> > only generated by the HP compilers (cc and aCC).
> > 
> > - Are these compilers still important for C?
> > - Are these compilers still important for C++?
> 
> We use them to build most of the free software we provide for our
> customers.
> 
> > I have not heard from any users of the FSF GDB with the HP compilers in
> > a long time; for HP-specific features, I suspect more people use HP's
> > WDB fork of GDB.  If no one is using the HP support, I would like to
> > remove it from the next release of GDB.
> 
> We ship GDB for all platforms except HP-UX, where we ship HP's WDB.

May I make sure I follow this correctly - on HP-UX, you use the aCC
compilers, but do not use GDB?

-- 
Daniel Jacobowitz
CodeSourcery

Re: Is anyone using the HP compilers on PA-RISC with FSF GDB?

[Albert Chin]

On Fri, Aug 04, 2006 at 08:50:32AM -0400, Daniel Jacobowitz wrote:
> On Fri, Aug 04, 2006 at 12:00:24AM -0500, Albert Chin wrote:
> > On Tue, Aug 01, 2006 at 10:55:30PM -0400, Daniel Jacobowitz wrote:
> > > 
> > > I have not heard from any users of the FSF GDB with the HP compilers in
> > > a long time; for HP-specific features, I suspect more people use HP's
> > > WDB fork of GDB.  If no one is using the HP support, I would like to
> > > remove it from the next release of GDB.
> > 
> > We ship GDB for all platforms except HP-UX, where we ship HP's WDB.
> 
> May I make sure I follow this correctly - on HP-UX, you use the aCC
> compilers, but do not use GDB?

Correct. WDB can debug binaries generated by aCC.

-- 
albert chin (china@thewrittenword.com)