From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2424 invoked by alias); 24 Feb 2012 11:12:35 -0000 Received: (qmail 2409 invoked by uid 22791); 24 Feb 2012 11:12:34 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,TW_NV X-Spam-Check-By: sourceware.org Received: from mel.act-europe.fr (HELO mel.act-europe.fr) (194.98.77.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 24 Feb 2012 11:12:21 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 3435429009A; Fri, 24 Feb 2012 12:12:21 +0100 (CET) Received: from mel.act-europe.fr ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXX1gq86AdyA; Fri, 24 Feb 2012 12:12:21 +0100 (CET) Received: from ulanbator.act-europe.fr (ulanbator.act-europe.fr [10.10.1.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mel.act-europe.fr (Postfix) with ESMTP id 206E4290011; Fri, 24 Feb 2012 12:12:21 +0100 (CET) Subject: Re: RFA: New port: ia64-hp-openvms - the stub Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Tristan Gingold In-Reply-To: <4F476A85.7040102@redhat.com> Date: Fri, 24 Feb 2012 11:24:00 -0000 Cc: "gdb-patches@sourceware.org ml" , Rupp Douglas Content-Transfer-Encoding: quoted-printable Message-Id: <39BA7DEE-B83F-4C64-A6D3-A870D6BACC73@adacore.com> 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> To: Pedro Alves X-IsSubscribed: yes 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/msg00539.txt.bz2 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. */ >>>>>=20 >>>>> What does this mean? Are we committing to a hack that will make our >>>>> lives hard when we want to fix it? >>>>=20 >>>> 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 adjuste= d. >>>=20 >>> Why don't we want to change it? >>=20 >> I think it's too late. That would be a change in gdbserver and other st= ubs, so it would break compatibility.=20=20 >=20 > We have ways to make it happen without breaking other stubs. The questio= n 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 ia= 64-tdep.c has to translate the convention. See for example the case of UNW_IA64_AR_BSP in ia64-tdep.c:ia64_access_reg. > The adjustment in the VMS stubs isn't that complex. >=20 > 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, whi= ch 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.