From mboxrd@z Thu Jan 1 00:00:00 1970 From: Elena Zannoni To: Daniel Berlin Cc: Elena Zannoni , Hilfinger@cs.berkeley.edu, gdb-patches@sources.redhat.com Subject: Re: Question concerning comment in symtab.h Date: Wed, 16 May 2001 21:30:00 -0000 Message-id: <15107.21476.149193.580656@kwikemart.cygnus.com> References: <15106.55172.717482.640326@kwikemart.cygnus.com> <200105161949.MAA15140@tully.CS.Berkeley.EDU> <15106.61691.835809.994768@kwikemart.cygnus.com> <87k83hj7mp.fsf@dynamic-addr-83-177.resnet.rochester.edu> X-SW-Source: 2001-05/msg00340.html Daniel Berlin writes: > Elena Zannoni 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 >