From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27391 invoked by alias); 22 Feb 2012 19:53:30 -0000 Received: (qmail 27383 invoked by uid 22791); 22 Feb 2012 19:53:29 -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; Wed, 22 Feb 2012 19:52:59 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1MJqk1h026315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 Feb 2012 14:52:46 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q1MJqj1L010802; Wed, 22 Feb 2012 14:52:45 -0500 Message-ID: <4F45478D.2030802@redhat.com> Date: Wed, 22 Feb 2012 20:25: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> In-Reply-To: <72064031-DC1B-4C92-B71A-15EFCC0C06F0@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/msg00487.txt.bz2 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. >>> +#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? It'd be good if the basics of using the stub were documented in the manual. In any case, this is okay. -- Pedro Alves