Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Marcel Moolenaar <marcel@xcllnt.net>
To: "J. Johnston" <jjohnstn@redhat.com>
Cc: Kevin Buettner <kevinb@redhat.com>, gdb-patches@sources.redhat.com
Subject: Re: RFA: ia64 tdep patch
Date: Wed, 22 Oct 2003 22:03:00 -0000	[thread overview]
Message-ID: <20031022220258.GA10464@dhcp01.pn.xcllnt.net> (raw)
In-Reply-To: <3F96EF3E.6070402@redhat.com>

On Wed, Oct 22, 2003 at 04:57:34PM -0400, J. Johnston wrote:
> >>>
> >>>Could you add a comment explaining why the normal method of computing
> >>>V32 (via ia64_pseudo_register_read()) is inadequate?
> >>
> >>I don't know.  I had this for safety reasons already in the
> >>ia64_frame_prev_register() because I didn't know if it might be
> >>called with the pseudo register number or not.  This code was
> >>copied.  Should it be removed in both places?
> >
> >
> >I don't know.  I've been studying the code and am wondering why the
> >V32 ... V127 pseudo regs were introduced at all.  Could you remind
> >me of the reason?
> >
> 
> They are needed because r32 to r127 are not accessible via the PTRACE 
> interface. They are accessed via the bsp.  Without flagging them as 
>  pseudo-registers, the regcache code returns 0 for all these registers.

It depends. For FreeBSD I added ptrace(2) functions to get and set
stacked registers that are on the kernel stack. The problem more
generally is that registers above bspstore (but below bsp) are
not accessable in memory. I think it's better for gdb to keep the
distinction between stacked registers on the backing store and
"dirty" stacked registers. The distinction avoids that gdb makes
assumptions that are only valid on Linux or even only for the native
code.

BTW: I have partial support for FreeBSD/ia64. I'll send patches as
soon as I feel that the backtrace is reliable enough.

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel@xcllnt.net


  parent reply	other threads:[~2003-10-22 22:03 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-17 19:58 J. Johnston
2003-10-20 20:13 ` Kevin Buettner
2003-10-20 21:55   ` J. Johnston
2003-10-21 22:22     ` Kevin Buettner
2003-10-21 23:03       ` J. Johnston
2003-10-22 19:38         ` Kevin Buettner
2003-10-22 20:57           ` J. Johnston
2003-10-22 22:01             ` J. Johnston
2003-10-23 16:22               ` J. Johnston
2003-10-23 17:46                 ` Kevin Buettner
2003-10-23 22:07                   ` J. Johnston
2003-10-22 22:03             ` Marcel Moolenaar [this message]
2003-10-23 21:01               ` Kevin Buettner
2003-10-23 23:23                 ` Marcel Moolenaar
2003-10-24  4:30                   ` Kevin Buettner
2003-10-24  5:40                     ` Marcel Moolenaar
2003-10-24  7:08                       ` Kevin Buettner

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=20031022220258.GA10464@dhcp01.pn.xcllnt.net \
    --to=marcel@xcllnt.net \
    --cc=gdb-patches@sources.redhat.com \
    --cc=jjohnstn@redhat.com \
    --cc=kevinb@redhat.com \
    /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