Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@cygnus.com>
To: Piet/Pete Delaney <piet@sgi.com>
Cc: Kevin Buettner <kevinb@redhat.com>, gdb@sources.redhat.com
Subject: Re: ia64-stub.c
Date: Wed, 23 Jan 2002 07:29:00 -0000	[thread overview]
Message-ID: <3C4ED6EE.7000502@cygnus.com> (raw)
In-Reply-To: <20020122234732.A59205@sgi.com>

> As noted above, there are a number of registers which are included in
>> the "g" packet which the IA-64 port disregards.  r32-r127 are retrieved
>> using an offset from BSP from the backing store (i.e, from memory).
>> The predicate registers are transferred in a single 64 bit word (the
>> pr register) and are split out to show individual 1-bit registers
>> by gdb.  Something similar occurs for the NaT bits.  Most of these
>> are indicated via a -1 in the u_offsets[] array.  (Some of these,
>> however, are simply not retrievable via the ptrace interface and
>> are therefore marked with -1.)
> 
> 
> In the kernel the registers may not always flushed out the the backing store.
> In a SPARC kernel a 2nd level trap is required for the kernel code to flush
> the registers to the backing store. A similar case may apply to ia64. Like
> in the even of a stack overflow (backing store isn't mapped). 


Please take anything you see in the SPARC with a grain of salt.  If 
someone were to implement the SPARC target today I think they would 
implement it very differently.  The register read/write architecture 
methods would most likely be used.  Those methods let an architecture 
map a register onto either memory or the register cache.


> I would think it preferable for gdb to accept values in the 'g' packet
> and if it doesn't receive a copy of the r32-r127 registers to then try
> to fetch them using an offset from the BSP.


I don't think that is possible with a G packet.  Several problems arise:

- If the target sends a short G packet then GDB assumes remaining 
registers are zero.

- on the wierd side, if a target supports the register-write packet GDB 
will write to those regsters.  However, if the register-write packet 
isn't supported then GDB won't write to them :-/

- there is a register unavailable indication (XXX in a G packet) but I 
don't know that its semantics extend to this case

I think persuing either a read-register packet (proposal posted some 
time back but never followed through) or, as kevin suggested, just 
saving the registers would be better.

enjoy,
Andrew




      parent reply	other threads:[~2002-01-23 15:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-21  1:00 ia64-stub.c Piet/Pete Delaney
2002-01-21 13:45 ` ia64-stub.c Kevin Buettner
     [not found]   ` <20020122105652.A57552@sgi.com>
     [not found]     ` <1020122190037.ZM5902@localhost.localdomain>
     [not found]       ` <20020122121956.B57552@sgi.com>
2002-01-22 12:51         ` ia64-stub.c Piet/Pete Delaney
2002-01-22 13:57           ` ia64-stub.c Kevin Buettner
2002-01-22 15:35             ` ia64-stub.c Piet/Pete Delaney
2002-01-22 18:27               ` ia64-stub.c Kevin Buettner
2002-01-22 23:47                 ` ia64-stub.c Piet/Pete Delaney
2002-01-23  3:16                   ` ia64-stub.c Kevin Buettner
2002-01-23  4:44                     ` ia64-stub.c Piet/Pete Delaney
2002-01-23  7:29                   ` Andrew Cagney [this message]

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=3C4ED6EE.7000502@cygnus.com \
    --to=ac131313@cygnus.com \
    --cc=gdb@sources.redhat.com \
    --cc=kevinb@redhat.com \
    --cc=piet@sgi.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