This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: Question concerning comment in symtab.h
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
>