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
prev 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