This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: assertion failure in regcache.c
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