* 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 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 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 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).