Re: Assuming types for PC

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> Date: Mon, 10 Jun 2013 19:04:08 +0100
> From: "Maciej W. Rozycki" <macro@codesourcery.com>
> 
> 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.