This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Question concerning comment in symtab.h


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.

And they are moving to dwarf2 anyway, or at least, wanted to.
>   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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]