From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29161 invoked by alias); 24 Feb 2012 10:47:10 -0000 Received: (qmail 29150 invoked by uid 22791); 24 Feb 2012 10:47:09 -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 10:46:53 +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 q1OAkV2W010994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Feb 2012 05:46:31 -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 q1OAkTXU015668; Fri, 24 Feb 2012 05:46:30 -0500 Message-ID: <4F476A85.7040102@redhat.com> Date: Fri, 24 Feb 2012 11:06: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> In-Reply-To: <6B97507D-F782-4A58-A10E-AD6A32CE49D6@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/msg00536.txt.bz2 On 02/24/2012 08:34 AM, Tristan Gingold wrote: > > On Feb 22, 2012, at 8:52 PM, Pedro Alves wrote: > >> On 02/21/2012 04:30 PM, Tristan Gingold wrote: >>> >>> On Feb 14, 2012, at 7:08 PM, Pedro Alves wrote: >> >>>> I couldn't really tell, but you may want to consider looking into xml target >>>> descriptions. At least reporting a description with the openvms osabi would >>>> be good. >>> >>> I plan to fix the register issue soon, just be patient ! >> >> I am. :-) A description with at least the osabi is good so that gdb >> knows the target's osabi even if the user doesn't supply an executable. > > Ok, shouldn't be hard to do. Just to implement qXfer:features:read, IIUC. Yeah. >>>>> +#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. Is this really Linux specific? We have ia64 hpux support as well. 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. 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. -- Pedro Alves