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


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


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