From: "Maciej W. Rozycki" <macro@codesourcery.com>
To: Mark Kettenis <mark.kettenis@xs4all.nl>,
Joel Brobecker <brobecker@adacore.com>
Cc: Luis Machado <lgustavo@codesourcery.com>, <gdb@sourceware.org>
Subject: Re: Assuming types for PC
Date: Mon, 10 Jun 2013 18:04:00 -0000 [thread overview]
Message-ID: <alpine.DEB.1.10.1306101838360.16287@tp.orcam.me.uk> (raw)
In-Reply-To: <201306101504.r5AF4pJJ010320@glazunov.sibelius.xs4all.nl>
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
next prev parent reply other threads:[~2013-06-10 18:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-10 14:19 Luis Machado
2013-06-10 14:31 ` Mark Kettenis
2013-06-10 14:34 ` Luis Machado
2013-06-10 14:45 ` Joel Brobecker
2013-06-10 14:49 ` Luis Machado
2013-06-10 14:56 ` Joel Brobecker
2013-06-10 15:04 ` Mark Kettenis
2013-06-10 15:18 ` Luis Machado
2013-06-10 18:04 ` Maciej W. Rozycki [this message]
2013-06-10 18:44 ` Mark Kettenis
2013-06-11 9:21 ` Pedro Alves
2013-06-11 10:09 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.1.10.1306101838360.16287@tp.orcam.me.uk \
--to=macro@codesourcery.com \
--cc=brobecker@adacore.com \
--cc=gdb@sourceware.org \
--cc=lgustavo@codesourcery.com \
--cc=mark.kettenis@xs4all.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox