From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18244 invoked by alias); 11 Jun 2013 10:09:16 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 18233 invoked by uid 89); 11 Jun 2013 10:09:15 -0000 X-Spam-SWARE-Status: No, score=-7.6 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 11 Jun 2013 10:09:11 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r5BA9678006597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Jun 2013 06:09:06 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r5BA93p0027656; Tue, 11 Jun 2013 06:09:04 -0400 Message-ID: <51B6F73F.3080505@redhat.com> Date: Tue, 11 Jun 2013 10:09:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: gdb@sourceware.org CC: Mark Kettenis , macro@codesourcery.com, brobecker@adacore.com, lgustavo@codesourcery.com Subject: Re: Assuming types for PC References: <51B5E06A.8020807@codesourcery.com> <201306101431.r5AEVAfb007850@glazunov.sibelius.xs4all.nl> <51B5E3D4.9010105@codesourcery.com> <201306101504.r5AF4pJJ010320@glazunov.sibelius.xs4all.nl> <201306101844.r5AIi8Ou017730@glazunov.sibelius.xs4all.nl> <51B6EC1F.3020401@redhat.com> In-Reply-To: <51B6EC1F.3020401@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-06/txt/msg00032.txt.bz2 On 06/11/2013 10:21 AM, Pedro Alves wrote: >>> Overall I think the test is too strict. If you think the use of "long >>> long" is unfortunate for the PC, then an artificial type might be created >>> internally within GDB specifically for the PC, similarly to what we do >>> e.g. for IEEE 754 data types and floating-point registers in some cases. >> >> An artificial type like that probably is the way to go. > > I agree. Something like the GDB equivalent of: > > typedef void * ptr64 __attribute ((mode(DI))); > > (That worked last time I tried it on x32, probably works on MIPS too.) > BTW, this whole issue is really a special case of an ABI register name colliding with a machine register name. A similar example came up when GDB was made to expose whole set of x86 general purpose registers. Specifically the $rsp/$rsp/$sp, where $sp (16-bit) collides with desire to use $sp to refer to stack pointer. An alternative idea I thrown out back then, would be to always leave $pc/$sp/$fp as the ABI version of the registers, and in case the machine has real registers by that name, expose those with an alternative naming, like e.g., $_pc/$_sp/$_fp. These would have the machine's full width. On i686, you'd get: 32-bit pointer $pc, 16-bit integer $ip, 32-bit pointer $eip. 32-bit pointer $sp, 16-bit integer $_sp, 32-bit pointer $esp. 32-bit pointer $fp, 16-bit integer $bp, 32-bit pointer $ebp. On x32, you'd get: 32-bit pointer $pc, 16-bit integer $ip, 32-bit pointer $eip, 64-bit integer $rip. 32-bit pointer $sp, 16-bit integer $_sp, 32-bit pointer $esp, 64-bit integer $rsp. 32-bit pointer $fp, 16-bit integer $bp, 32-bit pointer $ebp, 64-bit integer $rbp. On x86_64 (-m64), you'd get 64-bit pointer $pc, 16-bit integer $ip, 32-bit integer $eip, 64-bit pointer $rip. 64-bit pointer $sp, 16-bit integer $_sp, 32-bit integer $esp, 64-bit pointer $rsp. 64-bit pointer $fp, 16-bit integer $bp, 32-bit integer $ebp, 64-bit pointer $rbp. On MIPS n32, you'd get: 32-bit pointer $pc, 64-bit integer $_pc/$rNN. 32-bit pointer $sp, 64-bit integer $_sp/$rNN. 32-bit pointer $fp, 64-bit integer $_fp/$rNN. (the _ variants probably would be raw from any arch bit manipulation). (I'm not really sure which solution I prefer.) -- Pedro Alves