From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19088 invoked by alias); 10 Jun 2013 18:04:23 -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 19078 invoked by uid 89); 10 Jun 2013 18:04:22 -0000 X-Spam-SWARE-Status: No, score=-4.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL autolearn=ham version=3.3.1 Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 10 Jun 2013 18:04:21 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1Um6S3-0004oZ-MB from Maciej_Rozycki@mentor.com ; Mon, 10 Jun 2013 11:04:19 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Jun 2013 11:04:19 -0700 Received: from [172.30.64.211] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.2.247.3; Mon, 10 Jun 2013 19:04:18 +0100 Date: Mon, 10 Jun 2013 18:04:00 -0000 From: "Maciej W. Rozycki" To: Mark Kettenis , Joel Brobecker CC: Luis Machado , Subject: Re: Assuming types for PC In-Reply-To: <201306101504.r5AF4pJJ010320@glazunov.sibelius.xs4all.nl> Message-ID: References: <51B5E06A.8020807@codesourcery.com> <201306101431.r5AEVAfb007850@glazunov.sibelius.xs4all.nl> <51B5E3D4.9010105@codesourcery.com> <201306101504.r5AF4pJJ010320@glazunov.sibelius.xs4all.nl> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2013-06/txt/msg00028.txt.bz2 On Mon, 10 Jun 2013, Mark Kettenis wrote: > > >> If PC should not have a fixed type, i think it would be best to remove > > >> this check. > > > > > > Please don't. > > > > Is there a more elaborate reasoning for not removing this check? > > It serves a s a reminder that there are still issues to fix for some > of the architectures. Perhaps we should add a KFAIL for architectures > that have the 32-bit/64-bit identity crisis I mentioned. But other > architectures should just change the PC type to "code_ptr". That's not going to work for cases like MIPS n32 (the original cause of the failure) that is a 64-bit ILP32 ABI. There the PC like all the general registers is 64-bit wide and the pointer type is 32-bit, which is narrower than a register. This is solved by using the "long long" type as the register type (that type is specified by the ABI to occupy a single hardware register; also stack frames use slots of this size to store registers). I think it is important to let the user access the full width of the PC both for writes and -- more importantly -- for reads (as in: why did my program crash, did it jump to an odd place?), as this lets the user do with GDB what hardware permits. There is nothing in hardware that prevents one from writing an out-of-valid ABI address space value to the PC at a program's runtime (neither on Linux nor on bare iron) when executing an n32 program. I think GDB should not stand in a user's way and should allow the same to be done via ptrace(2) or RSP. 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. Joel, I hope this serves your: > Maybe another way of saying this would be "it should, unless proven > otherwise". In your case, it sounds like you are saying "it might", or > perhaps "some platforms don't", to which Mark is replying "show me" > (backed by the architecture manuals) :-) :-) :-). request for a justification... ... ah, you've asked for a manual too -- here's one then: http://techpubs.sgi.com/library/manuals/2000/007-2816-004/pdf/007-2816-004.pdf ;) Maciej