This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Assuming types for PC
- From: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- To: macro at codesourcery dot com
- Cc: brobecker at adacore dot com, lgustavo at codesourcery dot com, gdb at sourceware dot org
- Date: Mon, 10 Jun 2013 20:44:08 +0200 (CEST)
- Subject: Re: Assuming types for PC
- References: <51B5E06A dot 8020807 at codesourcery dot com> <201306101431 dot r5AEVAfb007850 at glazunov dot sibelius dot xs4all dot nl> <51B5E3D4 dot 9010105 at codesourcery dot com> <201306101504 dot r5AF4pJJ010320 at glazunov dot sibelius dot xs4all dot nl> <alpine dot DEB dot 1 dot 10 dot 1306101838360 dot 16287 at tp dot orcam dot me dot uk>
> 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.