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