* assertion failure in regcache.c
@ 2003-05-21 17:52 Kris Warkentin
2003-05-22 15:38 ` Andrew Cagney
0 siblings, 1 reply; 13+ messages in thread
From: Kris Warkentin @ 2003-05-21 17:52 UTC (permalink / raw)
To: Gdb@Sources.Redhat.Com; +Cc: Andrew Cagney
I just did an update and now I'm getting an assertion failure with my sh4
port.
gdb/regcache.c:241: internal-error: init_regcache_descr: Assertion
`descr->register_offset[i] == REGISTER_BYTE (i)' failed.
My code worked in the past few weeks so it looks like this is something
recent. The only change I can see to regcache.c and sh-tdep.c is to use
DEPRECATED_REGISTER_BYTES. Can anyone give any suggestions as to what might
be going wrong?
cheers,
Kris
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: assertion failure in regcache.c
2003-05-21 17:52 assertion failure in regcache.c Kris Warkentin
@ 2003-05-22 15:38 ` Andrew Cagney
2003-05-22 19:07 ` Kris Warkentin
0 siblings, 1 reply; 13+ messages in thread
From: Andrew Cagney @ 2003-05-22 15:38 UTC (permalink / raw)
To: Kris Warkentin; +Cc: Gdb@Sources.Redhat.Com
> I just did an update and now I'm getting an assertion failure with my sh4
> port.
>
> gdb/regcache.c:241: internal-error: init_regcache_descr: Assertion
> `descr->register_offset[i] == REGISTER_BYTE (i)' failed.
>
> My code worked in the past few weeks so it looks like this is something
> recent. The only change I can see to regcache.c and sh-tdep.c is to use
> DEPRECATED_REGISTER_BYTES. Can anyone give any suggestions as to what might
> be going wrong?
Can you go back to the ``working'' code and check the output from:
(gdb) maint print registers
(look for footnotes). I added a sanity check with:
2003-05-04 Andrew Cagney <cagney@redhat.com>
* sentinel-frame.c (sentinel_frame_prev_register): Replace
REGISTER_BYTE with register_offset_hack.
* regcache.c (init_regcache_descr): When REGISTER_BYTE_P, check
that REGISTER_BYTE is consistent with the regcache.
* gdbarch.sh (REGISTER_BYTE): Add a predicate.
* gdbarch.h, gdbarch.c: Regenerate.
however, I suspect that there has been long standing disagreement over
the offsets only nothing was noticing it :-/
Andrew
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: assertion failure in regcache.c
2003-05-22 15:38 ` Andrew Cagney
@ 2003-05-22 19:07 ` Kris Warkentin
2003-05-22 19:22 ` Andrew Cagney
0 siblings, 1 reply; 13+ messages in thread
From: Kris Warkentin @ 2003-05-22 19:07 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Gdb@Sources.Redhat.Com
Looks like you're right. If I update to 2003-05-04 it's fine, but after
that it blows up. Seems to only be a problem for sh4 though. Any
suggestions as to what might be breaking this? Here's the output of maint
print registers.
cheers,
Kris
Breakpoint 1, main () at float.c:22
22 a=324.235;
(gdb) maint print registers
Name Nr Rel Offset Size Type
r0 0 0 0 4 int
r1 1 1 4 4 int
r2 2 2 8 4 int
r3 3 3 12 4 int
r4 4 4 16 4 int
r5 5 5 20 4 int
r6 6 6 24 4 int
r7 7 7 28 4 int
r8 8 8 32 4 int
r9 9 9 36 4 int
r10 10 10 40 4 int
r11 11 11 44 4 int
r12 12 12 48 4 int
r13 13 13 52 4 int
r14 14 14 56 4 int
r15 15 15 60 4 int
pc 16 16 64 4 int
pr 17 17 68 4 int
gbr 18 18 72 4 int
vbr 19 19 76 4 int
mach 20 20 80 4 int
macl 21 21 84 4 int
sr 22 22 88 4 int
fpul 23 23 92 4 float
fpscr 24 24 96 4 int
fr0 25 25 100 4 float
fr1 26 26 104 4 float
fr2 27 27 108 4 float
fr3 28 28 112 4 float
fr4 29 29 116 4 float
fr5 30 30 120 4 float
fr6 31 31 124 4 float
fr7 32 32 128 4 float
fr8 33 33 132 4 float
fr9 34 34 136 4 float
fr10 35 35 140 4 float
fr11 36 36 144 4 float
fr12 37 37 148 4 float
fr13 38 38 152 4 float
fr14 39 39 156 4 float
fr15 40 40 160 4 float
ssr 41 41 164 4 int
spc 42 42 168 4 int
r0b0 43 43 172 4 int
r1b0 44 44 176 4 int
r2b0 45 45 180 4 int
r3b0 46 46 184 4 int
r4b0 47 47 188 4 int
r5b0 48 48 192 4 int
r6b0 49 49 196 4 int
r7b0 50 50 200 4 int
r0b1 51 51 204 4 int
r1b1 52 52 208 4 int
r2b1 53 53 212 4 int
r3b1 54 54 216 4 int
r4b1 55 55 220 4 int
r5b1 56 56 224 4 int
r6b1 57 57 228 4 int
r7b1 58 58 232 4 int
dr0 59 0 236*1 8 double
dr2 60 1 244*1 8 double
dr4 61 2 252*1 8 double
dr6 62 3 260*1 8 double
dr8 63 4 268*1 8 double
dr10 64 5 276*1 8 double
dr12 65 6 284*1 8 double
dr14 66 7 292*1 8 double
fv0 67 8 300*1 16 *2
fv4 68 9 316*1 16 *2
fv8 69 10 332*1 16 *2
fv12 70 11 348*1 16 *2
*1: Inconsistent register offsets.
*2: Register type's name NULL.
(gdb)
> > I just did an update and now I'm getting an assertion failure with my
sh4
> > port.
> >
> > gdb/regcache.c:241: internal-error: init_regcache_descr: Assertion
> > `descr->register_offset[i] == REGISTER_BYTE (i)' failed.
> >
> > My code worked in the past few weeks so it looks like this is something
> > recent. The only change I can see to regcache.c and sh-tdep.c is to use
> > DEPRECATED_REGISTER_BYTES. Can anyone give any suggestions as to what
might
> > be going wrong?
>
> Can you go back to the ``working'' code and check the output from:
>
> (gdb) maint print registers
>
> (look for footnotes). I added a sanity check with:
>
> 2003-05-04 Andrew Cagney <cagney@redhat.com>
>
> * sentinel-frame.c (sentinel_frame_prev_register): Replace
> REGISTER_BYTE with register_offset_hack.
> * regcache.c (init_regcache_descr): When REGISTER_BYTE_P, check
> that REGISTER_BYTE is consistent with the regcache.
> * gdbarch.sh (REGISTER_BYTE): Add a predicate.
> * gdbarch.h, gdbarch.c: Regenerate.
>
> however, I suspect that there has been long standing disagreement over
> the offsets only nothing was noticing it :-/
>
> Andrew
>
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: assertion failure in regcache.c
2003-05-22 19:07 ` Kris Warkentin
@ 2003-05-22 19:22 ` Andrew Cagney
2003-05-22 22:05 ` Elena Zannoni
0 siblings, 1 reply; 13+ messages in thread
From: Andrew Cagney @ 2003-05-22 19:22 UTC (permalink / raw)
To: Kris Warkentin; +Cc: Gdb@Sources.Redhat.Com
> Looks like you're right. If I update to 2003-05-04 it's fine, but after
> that it blows up. Seems to only be a problem for sh4 though. Any
> suggestions as to what might be breaking this? Here's the output of maint
> print registers.
> r0b1 51 51 204 4 int
> r1b1 52 52 208 4 int
> r2b1 53 53 212 4 int
> r3b1 54 54 216 4 int
> r4b1 55 55 220 4 int
> r5b1 56 56 224 4 int
> r6b1 57 57 228 4 int
> r7b1 58 58 232 4 int
> dr0 59 0 236*1 8 double
> dr2 60 1 244*1 8 double
> dr4 61 2 252*1 8 double
> dr6 62 3 260*1 8 double
> dr8 63 4 268*1 8 double
> dr10 64 5 276*1 8 double
> dr12 65 6 284*1 8 double
> dr14 66 7 292*1 8 double
> fv0 67 8 300*1 16 *2
> fv4 68 9 316*1 16 *2
> fv8 69 10 332*1 16 *2
> fv12 70 11 348*1 16 *2
> *1: Inconsistent register offsets.
> *2: Register type's name NULL.
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: assertion failure in regcache.c
2003-05-22 19:22 ` Andrew Cagney
@ 2003-05-22 22:05 ` Elena Zannoni
2003-05-23 17:36 ` Kris Warkentin
0 siblings, 1 reply; 13+ messages in thread
From: Elena Zannoni @ 2003-05-22 22:05 UTC (permalink / raw)
To: kewarken; +Cc: cagney, Gdb@Sources.Redhat.Com
Andrew Cagney writes:
> > Looks like you're right. If I update to 2003-05-04 it's fine, but after
> > that it blows up. Seems to only be a problem for sh4 though. Any
> > suggestions as to what might be breaking this? Here's the output of maint
> > print registers.
>
> > r0b1 51 51 204 4 int
> > r1b1 52 52 208 4 int
> > r2b1 53 53 212 4 int
> > r3b1 54 54 216 4 int
> > r4b1 55 55 220 4 int
> > r5b1 56 56 224 4 int
> > r6b1 57 57 228 4 int
> > r7b1 58 58 232 4 int
> > dr0 59 0 236*1 8 double
> > dr2 60 1 244*1 8 double
> > dr4 61 2 252*1 8 double
> > dr6 62 3 260*1 8 double
> > dr8 63 4 268*1 8 double
> > dr10 64 5 276*1 8 double
> > dr12 65 6 284*1 8 double
> > dr14 66 7 292*1 8 double
> > fv0 67 8 300*1 16 *2
> > fv4 68 9 316*1 16 *2
> > fv8 69 10 332*1 16 *2
> > fv12 70 11 348*1 16 *2
> > *1: Inconsistent register offsets.
> > *2: Register type's name NULL.
>
> 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.
elena
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: assertion failure in regcache.c
2003-05-22 22:05 ` Elena Zannoni
@ 2003-05-23 17:36 ` Kris Warkentin
2003-05-23 18:22 ` Elena Zannoni
0 siblings, 1 reply; 13+ messages in thread
From: Kris Warkentin @ 2003-05-23 17:36 UTC (permalink / raw)
To: Elena Zannoni; +Cc: cagney, Gdb@Sources.Redhat.Com
> > 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.
Where do I go from here?
cheers,
Kris
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: assertion failure in regcache.c
2003-05-23 17:36 ` Kris Warkentin
@ 2003-05-23 18:22 ` Elena Zannoni
2003-05-23 19:23 ` Kris Warkentin
2003-05-23 19:47 ` Andrew Cagney
0 siblings, 2 replies; 13+ messages in thread
From: Elena Zannoni @ 2003-05-23 18:22 UTC (permalink / raw)
To: Kris Warkentin; +Cc: Elena Zannoni, cagney, Gdb@Sources.Redhat.Com
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: assertion failure in regcache.c
2003-05-23 18:22 ` Elena Zannoni
@ 2003-05-23 19:23 ` Kris Warkentin
2003-05-23 20:29 ` Andrew Cagney
2003-05-23 19:47 ` Andrew Cagney
1 sibling, 1 reply; 13+ messages in thread
From: Kris Warkentin @ 2003-05-23 19:23 UTC (permalink / raw)
To: Elena Zannoni; +Cc: Elena Zannoni, cagney, Gdb@Sources.Redhat.Com
> Maybe we should be using the legacy
> version of the regcache init function? Is that doable?
The conditions for using init_legacy_regcache_descr seem to be the target
not having a gdbarch pseudo_register_read_p, pseudo_register_write_p and a
register_type_p. It has the first two but not the third so we either figure
out a way to get rid of the pseudo stuff or we finish making regcache take
pseudo registers into account.
cheers,
Kris
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: assertion failure in regcache.c
2003-05-23 18:22 ` Elena Zannoni
2003-05-23 19:23 ` Kris Warkentin
@ 2003-05-23 19:47 ` Andrew Cagney
2003-05-23 20:29 ` Kris Warkentin
1 sibling, 1 reply; 13+ messages in thread
From: Andrew Cagney @ 2003-05-23 19:47 UTC (permalink / raw)
To: Elena Zannoni, Kris Warkentin; +Cc: Gdb@Sources.Redhat.Com
> 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.
Plan B. Try not setting [deprecated_]register_byte.
> 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?
Are we all sitting comfortably? I'll try to explain the history to this
... :-)
Long ago, the code for reading/writing register values looked like (this
was burried in read_register_bytes):
extract_integer (®isters[value->address], value->length);
That is, given $dr5, gdb would create a value the location of which was
described by:
location = lval_register;
regnum = $dr5 regnum
address = REGISTER_BYTE ($dr5 regnum)
and then, assuming that the register cache was one big byte array, and
that the value was already in that array, and that they array only held
raw registers, use the ADDRESS and not the REGNUM to extract the value's
raw bytes.
This forced the SH (and a few other architectures) to directly map
pseudo registers onto the raw register range (to guarentee that the
value read was always valid).
Fortunatly, since then problems like this have (hopefully) all been
identified and fixed. It uses a read / modify / write to access the values:
- map the [value->address, value->length) back to a sequence of
registers (identified by their register number). Here, they would be
pseudo registers
- read, using regcache_cooked_read, those registers and contatenate
them into a large buffer
- ``modify'' the bytes implied by [value->address, value->length)
- write, using regcache_cooked_write, each of the registers back into
the regcache
The procedural interface means that something like $dr5 is always
constructed / updated on the fly (using the relevant raw registers), and
potential problems with out-dated register values are avoided.
In the end, GDB doesn't store multiple values of the same register, but
it can end up caching the various values. That doesn't matter, GDB
flushes all such cached values after any target modify.
enjoy,
Andrew
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: assertion failure in regcache.c
2003-05-23 19:47 ` Andrew Cagney
@ 2003-05-23 20:29 ` Kris Warkentin
2003-05-23 20:33 ` Elena Zannoni
0 siblings, 1 reply; 13+ messages in thread
From: Kris Warkentin @ 2003-05-23 20:29 UTC (permalink / raw)
To: Andrew Cagney, Elena Zannoni; +Cc: Gdb@Sources.Redhat.Com
Interesting. If I go through sh-tdep.c and comment out all the
'set_gdbarch_register_byte(blah)' calls, it works. Are there any potential
negative implications of this or can we just trust regcache to do it's job?
cheers,
Kris
----- Original Message -----
From: "Andrew Cagney" <ac131313@redhat.com>
To: "Elena Zannoni" <ezannoni@redhat.com>; "Kris Warkentin"
<kewarken@qnx.com>
Cc: "Gdb@Sources.Redhat.Com" <gdb@sources.redhat.com>
Sent: Friday, May 23, 2003 3:46 PM
Subject: 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.
>
> Plan B. Try not setting [deprecated_]register_byte.
>
> > 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?
>
> Are we all sitting comfortably? I'll try to explain the history to this
> ... :-)
>
> Long ago, the code for reading/writing register values looked like (this
> was burried in read_register_bytes):
>
> extract_integer (®isters[value->address], value->length);
>
> That is, given $dr5, gdb would create a value the location of which was
> described by:
>
> location = lval_register;
> regnum = $dr5 regnum
> address = REGISTER_BYTE ($dr5 regnum)
>
> and then, assuming that the register cache was one big byte array, and
> that the value was already in that array, and that they array only held
> raw registers, use the ADDRESS and not the REGNUM to extract the value's
> raw bytes.
>
> This forced the SH (and a few other architectures) to directly map
> pseudo registers onto the raw register range (to guarentee that the
> value read was always valid).
>
> Fortunatly, since then problems like this have (hopefully) all been
> identified and fixed. It uses a read / modify / write to access the
values:
>
> - map the [value->address, value->length) back to a sequence of
> registers (identified by their register number). Here, they would be
> pseudo registers
> - read, using regcache_cooked_read, those registers and contatenate
> them into a large buffer
> - ``modify'' the bytes implied by [value->address, value->length)
> - write, using regcache_cooked_write, each of the registers back into
> the regcache
>
> The procedural interface means that something like $dr5 is always
> constructed / updated on the fly (using the relevant raw registers), and
> potential problems with out-dated register values are avoided.
>
> In the end, GDB doesn't store multiple values of the same register, but
> it can end up caching the various values. That doesn't matter, GDB
> flushes all such cached values after any target modify.
>
> enjoy,
> Andrew
>
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: assertion failure in regcache.c
2003-05-23 19:23 ` Kris Warkentin
@ 2003-05-23 20:29 ` Andrew Cagney
0 siblings, 0 replies; 13+ messages in thread
From: Andrew Cagney @ 2003-05-23 20:29 UTC (permalink / raw)
To: Kris Warkentin; +Cc: Elena Zannoni, Gdb@Sources.Redhat.Com
>> Maybe we should be using the legacy
>> version of the regcache init function? Is that doable?
> The conditions for using init_legacy_regcache_descr seem to be the target
> not having a gdbarch pseudo_register_read_p, pseudo_register_write_p and a
> register_type_p.
That would be a backwards step.
> It has the first two but not the third so we either figure
> out a way to get rid of the pseudo stuff or we finish making regcache take
> pseudo registers into account.
That isn't correct. See my other post.
Andrew
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: assertion failure in regcache.c
2003-05-23 20:29 ` Kris Warkentin
@ 2003-05-23 20:33 ` Elena Zannoni
2003-05-23 20:39 ` Kris Warkentin
0 siblings, 1 reply; 13+ messages in thread
From: Elena Zannoni @ 2003-05-23 20:33 UTC (permalink / raw)
To: Kris Warkentin; +Cc: Andrew Cagney, Elena Zannoni, Gdb@Sources.Redhat.Com
Kris Warkentin writes:
> Interesting. If I go through sh-tdep.c and comment out all the
> 'set_gdbarch_register_byte(blah)' calls, it works. Are there any potential
> negative implications of this or can we just trust regcache to do it's job?
>
Oh my. I have fainted. It works? :-) You mean all that pseudo
register stuff written 2+ years back still works with all the register
changes? I really think that working on gdb is just like the Boston
Big Dig.
What exactly do you mean by it works? Testsuite failures approach
acceptable levels? This is only sh4, right? There are so many variants
to test. The really scary one would be sh64.
elena
> cheers,
>
> Kris
>
> ----- Original Message -----
> From: "Andrew Cagney" <ac131313@redhat.com>
> To: "Elena Zannoni" <ezannoni@redhat.com>; "Kris Warkentin"
> <kewarken@qnx.com>
> Cc: "Gdb@Sources.Redhat.Com" <gdb@sources.redhat.com>
> Sent: Friday, May 23, 2003 3:46 PM
> Subject: 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.
> >
> > Plan B. Try not setting [deprecated_]register_byte.
> >
> > > 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?
> >
> > Are we all sitting comfortably? I'll try to explain the history to this
> > ... :-)
> >
> > Long ago, the code for reading/writing register values looked like (this
> > was burried in read_register_bytes):
> >
> > extract_integer (®isters[value->address], value->length);
> >
> > That is, given $dr5, gdb would create a value the location of which was
> > described by:
> >
> > location = lval_register;
> > regnum = $dr5 regnum
> > address = REGISTER_BYTE ($dr5 regnum)
> >
> > and then, assuming that the register cache was one big byte array, and
> > that the value was already in that array, and that they array only held
> > raw registers, use the ADDRESS and not the REGNUM to extract the value's
> > raw bytes.
> >
> > This forced the SH (and a few other architectures) to directly map
> > pseudo registers onto the raw register range (to guarentee that the
> > value read was always valid).
> >
> > Fortunatly, since then problems like this have (hopefully) all been
> > identified and fixed. It uses a read / modify / write to access the
> values:
> >
> > - map the [value->address, value->length) back to a sequence of
> > registers (identified by their register number). Here, they would be
> > pseudo registers
> > - read, using regcache_cooked_read, those registers and contatenate
> > them into a large buffer
> > - ``modify'' the bytes implied by [value->address, value->length)
> > - write, using regcache_cooked_write, each of the registers back into
> > the regcache
> >
> > The procedural interface means that something like $dr5 is always
> > constructed / updated on the fly (using the relevant raw registers), and
> > potential problems with out-dated register values are avoided.
> >
> > In the end, GDB doesn't store multiple values of the same register, but
> > it can end up caching the various values. That doesn't matter, GDB
> > flushes all such cached values after any target modify.
> >
> > enjoy,
> > Andrew
> >
> >
> >
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: assertion failure in regcache.c
2003-05-23 20:33 ` Elena Zannoni
@ 2003-05-23 20:39 ` Kris Warkentin
0 siblings, 0 replies; 13+ messages in thread
From: Kris Warkentin @ 2003-05-23 20:39 UTC (permalink / raw)
To: Elena Zannoni; +Cc: Andrew Cagney, Elena Zannoni, Gdb@Sources.Redhat.Com
> Kris Warkentin writes:
> > Interesting. If I go through sh-tdep.c and comment out all the
> > 'set_gdbarch_register_byte(blah)' calls, it works. Are there any
potential
> > negative implications of this or can we just trust regcache to do it's
job?
> >
>
> Oh my. I have fainted. It works? :-) You mean all that pseudo
> register stuff written 2+ years back still works with all the register
> changes? I really think that working on gdb is just like the Boston
> Big Dig.
>
> What exactly do you mean by it works? Testsuite failures approach
> acceptable levels? This is only sh4, right? There are so many variants
> to test. The really scary one would be sh64.
By 'works', I mean, "I didn't choke on the assertion and I managed to
successfully debug a program and look at registers." That's probably not
the definitive test by any stretch but it's better than gdb dumping core.
The fact of the matter is, I only care about sh4 so I would be happy with
getting rid of just the sh4_register_byte thing and letting other sh
concerned parties deal with their versions themselves. I'll bet you dimes
to donuts that every other sh target will have this problem with the head
branch too.
If you guys can suggest some other work that I might be able to do to fix
this for everyone in a nice way I might be able to help out though since
it's certainly in my interest to have sh working on the head.
cheers,
Kris
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2003-05-23 20:39 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-21 17:52 assertion failure in regcache.c 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
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
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).