Re: Question concerning comment in symtab.h

[Daniel Berlin <dan@cgsoftware.com>]

Paul Hilfinger <hilfingr@EECS.Berkeley.EDU> 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? 

The second, of course. I figured as much (that you wanted to improve
HP compiled code), too.  Maybe you know enough
about HP aCC to fix a problem in hpacc-abi.c (an unsubmitted version)
with figuring out virtual table location?

>  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).

Well, hmmm.
Can't we handle this in the symbol reader?


> 
> Paul Hilfinger

-- 
"My roommate got a pet elephant.  Then it got lost.  It's in the
apartment somewhere.
"-Steven Wright