Re: Question concerning comment in symtab.h

[Elena Zannoni <ezannoni@cygnus.com>]

Daniel Berlin writes:
 > Elena Zannoni <ezannoni@cygnus.com> writes:
 > 
 > > Paul Hilfinger writes:
 > >  > 
 > >  > >This code in valops.c was added to handle HP's native compiler. I am
 > >  > >really tempted to just remove it, because it breaks function calls
 > >  > >with function pointers as parameters for all the cases in which gcc is
 > >  > >not used. I am going to submit a patch to get rid of this code.
 > >  > 
 > >  > >If I do that, I think the only remaining use of gcc_compile_flag
 > >  > >outside of the symbol readers is in generic_use_struct_convention in
 > >  > >values.c, and it is used to distinguish between different versions of
 > >  > >gcc (specifically 2.0 to 2.3.3, vs. all the others). I wonder if this
 > >  > >could be eliminated as well.
 > >  > 
 > >  > Well, as a matter of fact, I was grubbing around here precisely in
 > >  > order to enhance support for debugging native-HP-compiled code---WHAT
 > >  > an odd coincidence.  Are you saying you DON'T want to support HP-
 > >  > native-compiled code, or are you saying that we should move to a better
 > >  > approach?  If, as I hope, you mean the latter, could we agree on The
 > >  > Right Way to do this?  The specific problem I am struggling with is
 > >  > that GCC does not entirely conform to HP's ABI for stack-unwinding
 > >  > info (specifically, it slightly misuses the SAVE_SP bit: see also
 > >  > previous messages from me on this).
 > >  > 
 > > 
 > > I wanted to get rid of the hack. I am not sure what the right way to
 > > provide that functionality is, at the moment. I don't know if the HP
 > > native compiler has changed since that code was put in. Do you know if
 > > that hack is still necessary? 
 > > [I wonder what HP's WDB does nowadays. Have you looked at that?]
 > > 
 > > If you look in hp-symtab-read.c, processing_gcc_compilation is set to
 > > 0, which is wrong, I think, because that file is used to process gcc
 > > compiled files as well as aCC compiled files.
 > 
 > Eerr, no, this is wrong. AFAIK, only HP's compiler produces that type
 > of debug info.

Ok, so what does gcc produces on HPUX?

 > 
 > And they are moving to dwarf2 anyway, or at least, wanted to.

Yeah, but we should keep some degree of backwards compatibility.

Thanks
Elena

 > >   Does HP's compiler
 > > still use SOM? And what does gcc emit on hpux?  Note that there is
 > > another variable with a similar purpose, hp_som_som_object_present,
 > > maybe that could be unified/integrated with the function pointer
 > > hack.
 > 
 > 
 > > 
 > > I don't remember much about HP's stack layout, so I can't help much
 > > here, sorry. 
 > > 
 > > The HP platform is in pretty bad shape right now, any improvement
 > > would be good.
 > > 
 > > Elena
 > > 
 > >  > Paul Hilfinger
 > >  > 
 > 
 > -- 
 > "Do you think that when they asked George Washington for ID that
 > he just whipped out a quarter?
 > "-Steven Wright
 >