Re: Assuming types for PC

Mark Kettenis
2013-06-10T18:44:25Z

> 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.