From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12963 invoked by alias); 10 Jun 2013 18:44:25 -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 12922 invoked by uid 89); 10 Jun 2013 18:44:19 -0000 X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RP_MATCHES_RCVD autolearn=ham version=3.3.1 Received: from sibelius.xs4all.nl (HELO glazunov.sibelius.xs4all.nl) (83.163.83.176) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 10 Jun 2013 18:44:18 +0000 Received: from glazunov.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by glazunov.sibelius.xs4all.nl (8.14.5/8.14.3) with ESMTP id r5AIi99T031332; Mon, 10 Jun 2013 20:44:09 +0200 (CEST) Received: (from kettenis@localhost) by glazunov.sibelius.xs4all.nl (8.14.5/8.14.3/Submit) id r5AIi8Ou017730; Mon, 10 Jun 2013 20:44:08 +0200 (CEST) Date: Mon, 10 Jun 2013 18:44:00 -0000 Message-Id: <201306101844.r5AIi8Ou017730@glazunov.sibelius.xs4all.nl> From: Mark Kettenis To: macro@codesourcery.com CC: brobecker@adacore.com, lgustavo@codesourcery.com, gdb@sourceware.org In-reply-to: (macro@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> X-SW-Source: 2013-06/txt/msg00029.txt.bz2 > Date: Mon, 10 Jun 2013 19:04:08 +0100 > From: "Maciej W. Rozycki" > > 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). Yes, MIPS n32 is one of those architectures with a 32-bit/64-bit identity crisis ;). > 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. Absolutely! > 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.