From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8612 invoked by alias); 28 Jan 2003 04:15:05 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 8604 invoked from network); 28 Jan 2003 04:15:02 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (80.14.53.12) by 172.16.49.205 with SMTP; 28 Jan 2003 04:15:02 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id E8FC4D34AE; Tue, 28 Jan 2003 08:14:55 +0400 (RET) Date: Tue, 28 Jan 2003 04:15:00 -0000 From: Joel Brobecker To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: HP/UX 64 need CALL_DUMMY_LOCATION ON_STACK? Message-ID: <20030128041455.GG6437@gnat.com> References: <3E2B59FE.8090401@redhat.com> <20030120030414.GK5477@gnat.com> <3E2B7A8E.6050403@redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline In-Reply-To: <3E2B7A8E.6050403@redhat.com> User-Agent: Mutt/1.4i X-SW-Source: 2003-01/txt/msg00752.txt.bz2 --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 1122 Andrew, I finally had a look at this problem. > >I'll try to have a look today (thanks for this notice!). > > I'd better explain why I think I broke it :-/ I believe the old code > had the sequence: > > tm-hppa64.h: > #include "tm-hppa.h" > tm-hppa.h: > #define CALL_DUMMY_LOCATION ON_STACK > #undef CALL_DUMMY_LOCATION I believe you are right. I did a bit of archeology, but could not find the purpose of this undef. Before you added the '#define CALL_DUMMY_LOCATION ON_STACK' when you changed the default value for CALL_DUMMY_LOCATION, there was no such defined in tm-hppa.h... So the undef was useless, and now seems to cause some breakage on hppa64. Short of understanding completely the issues at hand, I simply ran the testsuite with and without the #undef, and found that that results are sensibly better without (ie, to my relief, you guess right about hppa64). I have the following change ready: 2003-01-28 J. Brobecker * config/pa/tm-hppa64.h (CALL_DUMMY_LOCATION): Remove #undef causing some regressions due to a change in the default value for this macro. -- Joel --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="tm-hppa64.h" Content-length: 525 Index: config/pa/tm-hppa64.h =================================================================== RCS file: /cvs/src/src/gdb/config/pa/tm-hppa64.h,v retrieving revision 1.6 diff -c -3 -p -r1.6 tm-hppa64.h *** config/pa/tm-hppa64.h 14 Nov 2002 00:25:05 -0000 1.6 --- config/pa/tm-hppa64.h 28 Jan 2003 04:12:36 -0000 *************** call_dummy *** 217,223 **** #undef FUNC_LDO_OFFSET #undef SR4EXPORT_LDIL_OFFSET #undef SR4EXPORT_LDO_OFFSET - #undef CALL_DUMMY_LOCATION #undef REG_STRUCT_HAS_ADDR --- 217,222 ---- --M9NhX3UHpAaciwkO--