assertion failure in regcache.c

assertion failure in regcache.c

[Kris Warkentin]

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

Re: assertion failure in regcache.c

[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?

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

Re: assertion failure in regcache.c

[Kris Warkentin]

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

Re: assertion failure in regcache.c

[Andrew Cagney]

> 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

Re: assertion failure in regcache.c

[Elena Zannoni]

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

Re: assertion failure in regcache.c

[Kris Warkentin]

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

Re: assertion failure in regcache.c

[Elena Zannoni]

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

Re: assertion failure in regcache.c

[Kris Warkentin]

> 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

Re: assertion failure in regcache.c

[Andrew Cagney]

> 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 (&registers[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

Re: assertion failure in regcache.c

[Kris Warkentin]

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 (&registers[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
>
>
>

Re: assertion failure in regcache.c

[Andrew Cagney]

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

Re: assertion failure in regcache.c

[Elena Zannoni]

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 (&registers[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
 > >
 > >
 > >

Re: assertion failure in regcache.c

[Kris Warkentin]

> 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