Mirror of the gdb mailing list
 help / color / mirror / Atom feed
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


  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