From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7308 invoked by alias); 24 Feb 2012 11:24:59 -0000 Received: (qmail 7299 invoked by uid 22791); 24 Feb 2012 11:24:58 -0000 X-SWARE-Spam-Status: No, hits=-6.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_NV,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 24 Feb 2012 11:24:40 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1OBORJj031110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Feb 2012 06:24:27 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q1OBOQf1030808; Fri, 24 Feb 2012 06:24:26 -0500 Message-ID: <4F47736A.8010608@redhat.com> Date: Fri, 24 Feb 2012 12:17:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 To: Tristan Gingold CC: "gdb-patches@sourceware.org ml" , Rupp Douglas Subject: Re: RFA: New port: ia64-hp-openvms - the stub References: <6AD2487F-8409-4F4E-93A6-9DB7FD195E71@adacore.com> <35B93121-2F70-4E7C-B415-E691138D6698@adacore.com> <4F3AA334.8000409@redhat.com> <72064031-DC1B-4C92-B71A-15EFCC0C06F0@adacore.com> <4F45478D.2030802@redhat.com> <6B97507D-F782-4A58-A10E-AD6A32CE49D6@adacore.com> <4F476A85.7040102@redhat.com> <39BA7DEE-B83F-4C64-A6D3-A870D6BACC73@adacore.com> In-Reply-To: <39BA7DEE-B83F-4C64-A6D3-A870D6BACC73@adacore.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-02/txt/msg00540.txt.bz2 On 02/24/2012 11:12 AM, Tristan Gingold wrote: > > On Feb 24, 2012, at 11:46 AM, Pedro Alves wrote: > >>>>>>> +#if 1 >>>>>>> + /* What a mess. Gdb and linux expects bsp to point after the current >>>>>>> + register frame. Adjust. */ >>>>>> >>>>>> What does this mean? Are we committing to a hack that will make our >>>>>> lives hard when we want to fix it? >>>>> >>>>> I have updated the comment. Currently, ia64-tdep.c follows the Linux convention, and we don't want to change that. So the BSP has to be adjusted. >>>> >>>> Why don't we want to change it? >>> >>> I think it's too late. That would be a change in gdbserver and other stubs, so it would break compatibility. >> >> We have ways to make it happen without breaking other stubs. The question is what is the >> right thing to do. > > I am not sure that modifying the convention of BSP is the right thing to do. > >> Is this really Linux specific? We have ia64 hpux support as well. > > AFAIU, hpux also follows the Linux convention. > >> I take it libunwind must follow the same convention as well, and I hope a libunwind >> built on a Linux host doesn't behave different from a libunwind built on a >> different host. > > That's correct. libunwind convention matches the VMS one, and therefore ia64-tdep.c has to translate the convention. > See for example the case of UNW_IA64_AR_BSP in ia64-tdep.c:ia64_access_reg. Damn, what a mess... If we want to fix this, getting rid of the unnecessary conversions all around, we can do it with a xml target description with a new standard feature (org.gnu.gdb.ia64.something) so that gdb knows the registers are sent with the libunwind/vms convention. Without that, yes, we should feed the raw register set as gdb has been expecting it. > >> The adjustment in the VMS stubs isn't that complex. >> >> Hopefully it'll still be simple with infcalls in the game. :-) afaics, you're >> not undoing the adjustment on writes. > > Correct. Writing this register is used only to implement inferior call, which is not yet implemented. The user will never modify it > directly, as this value cannot be changed without modifying other registers. HPUX even don't allow to modify it (for not so bad reasons). > Welcome in ia64 world! > > Tristan. > -- Pedro Alves