From: Elena Zannoni <ezannoni@redhat.com>
To: "Kris Warkentin" <kewarken@qnx.com>
Cc: "Elena Zannoni" <ezannoni@redhat.com>, <cagney@redhat.com>,
"Gdb@Sources.Redhat.Com" <gdb@sources.redhat.com>
Subject: Re: assertion failure in regcache.c
Date: Fri, 23 May 2003 18:22:00 -0000 [thread overview]
Message-ID: <16078.26357.742030.751293@localhost.redhat.com> (raw)
In-Reply-To: <11d801c32151$c37bbd80$0202040a@catdog>
Kris Warkentin writes:
> > > I'd start with the obvious thing - a simple tipo in the SH4 register
> > > byte function. The code was written long before these sanity checks
> > > were added and ``the old way'' makes it very hard to notice that the
> > > values are skewed.
> > >
> > > Andrew
> > >
> >
> >
> > yes, look at sh_sh4_register_byte. Maybe FV0_REGNUM or FV_LAST_REGNUM
> > are not set correctly or fv_reg_base_num does something wrong. These
> > registers with (*1) are pseudo registers, so it's easy that the
> > calculations could have been screwed up.
>
> Well, I found the disagreement. It looks to me like
> regcache->descr->register_offset[] is pointing to an upwardly growing list
> of registers including the pseudo-registers. So you get something like dr5
> being 260 in the register_offset array but sh4_register_byte will return 124
> which would be the offset of fr10 (taking into account that dr0 is overlaid
> on top of the fr regs). I'm inclined to think that the regcache way is
> wrong since someone who updates dr0 and then reads fr0 will get conflicting
> values. We shouldn't be storing extra copies of the same register.
Looking at regcache.c I see that the long term goal is to not allocate
space in the regcache for the PSEUDOs. But in the meantime,
descr->register_offset[i] = REGISTER_BYTE (i);
in the legacy init function, while
descr->sizeof_register[i] = TYPE_LENGTH (descr->register_type[i]);
descr->register_offset[i] = offset;
offset += descr->sizeof_register[i];
in the new version of the function.
So the mismatch seems to come from the TYPE_LENGTH() on the type of a
pseudo, because that's always a positive quantity, while the
REGISTER_BYTE points 'backwards'. Maybe we should be using the legacy
version of the regcache init function? Is that doable?
elena
>
> Where do I go from here?
>
> cheers,
>
> Kris
next prev parent reply other threads:[~2003-05-23 18:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-21 17:52 Kris Warkentin
2003-05-22 15:38 ` Andrew Cagney
2003-05-22 19:07 ` Kris Warkentin
2003-05-22 19:22 ` Andrew Cagney
2003-05-22 22:05 ` Elena Zannoni
2003-05-23 17:36 ` Kris Warkentin
2003-05-23 18:22 ` Elena Zannoni [this message]
2003-05-23 19:23 ` Kris Warkentin
2003-05-23 20:29 ` Andrew Cagney
2003-05-23 19:47 ` Andrew Cagney
2003-05-23 20:29 ` Kris Warkentin
2003-05-23 20:33 ` Elena Zannoni
2003-05-23 20:39 ` Kris Warkentin
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=16078.26357.742030.751293@localhost.redhat.com \
--to=ezannoni@redhat.com \
--cc=cagney@redhat.com \
--cc=gdb@sources.redhat.com \
--cc=kewarken@qnx.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).