Re: GDB respin

Re: GDB respin

[Michael Elizabeth Chastain]

Michal Ludvig mailed me some gdb.log files for x86_64 and I had
a superficial look.  This is for gdb:

  GNU gdb 2003-02-01-cvs
  Copyright 2003 Free Software Foundation, Inc.
  GDB is free software, covered by the GNU General Public License, and you are
  welcome to change it and/or distribute copies of it under certain conditions.
  Type "show copying" to see the conditions.
  There is absolutely no warranty for GDB.  Type "show warranty" for details.
  This GDB was configured as "x86_64-unknown-linux-gnu".

This gdb has some new internal errors.
All of these are new, compared to gdb 5.3.

     49	gdb.log:../../gdb-head/gdb/sentinel-frame.c:102: internal-error: Function sentinal_frame_pop called
      3	gdb.log:../../gdb-head/gdb/regcache.c:713: internal-error: regcache_raw_read: Assertion `regcache != NULL && buf != NULL' failed.
      5	gdb.log:../../gdb-head/gdb/gdbarch.c:4271: internal-error: gdbarch: gdbarch_store_return_value invalid
      2	gdb.log:&"../../gdb-head/gdb/gdbarch.c:4252: internal-error: gdbarch: gdbarch_extract_return_value invalid\n"
      6	gdb.log:../../gdb-head/gdb/gdbarch.c:4252: internal-error: gdbarch: gdbarch_extract_return_value invalid

The first number is a count.  So there were 49 instances of
'internal-error: Function sentinal_frame_pop' called.

Can anyone speak to these internal-errors?  
Do some of them have obvious easy fixes?

Michael C

Re: GDB respin

[Andrew Cagney]

Can someone post backtraces?

      49	gdb.log:../../gdb-head/gdb/sentinel-frame.c:102: 
internal-error: Function sentinal_frame_pop called

Er, this should shouldn't happen.  Backtrace?

       3	gdb.log:../../gdb-head/gdb/regcache.c:713: internal-error: 
regcache_raw_read: Assertion `regcache != NULL && buf != NULL' failed.

Again, the caller is pretty messed up.

       5	gdb.log:../../gdb-head/gdb/gdbarch.c:4271: internal-error: 
gdbarch: gdbarch_store_return_value invalid
       2	gdb.log:&"../../gdb-head/gdb/gdbarch.c:4252: internal-error: 
gdbarch: gdbarch_extract_return_value invalid\n"
       6	gdb.log:../../gdb-head/gdb/gdbarch.c:4252: internal-error: 
gdbarch: gdbarch_extract_return_value invalid


Andrew

Re: GDB respin

[Elena Zannoni]

Andrew Cagney writes:
 > Can someone post backtraces?
 > 
 >       49	gdb.log:../../gdb-head/gdb/sentinel-frame.c:102: 
 > internal-error: Function sentinal_frame_pop called
 > 
 > Er, this should shouldn't happen.  Backtrace?
 > 
 >        3	gdb.log:../../gdb-head/gdb/regcache.c:713: internal-error: 
 > regcache_raw_read: Assertion `regcache != NULL && buf != NULL' failed.
 > 
 > Again, the caller is pretty messed up.
 > 
 >        5	gdb.log:../../gdb-head/gdb/gdbarch.c:4271: internal-error: 
 > gdbarch: gdbarch_store_return_value invalid
 >        2	gdb.log:&"../../gdb-head/gdb/gdbarch.c:4252: internal-error: 
 > gdbarch: gdbarch_extract_return_value invalid\n"
 >        6	gdb.log:../../gdb-head/gdb/gdbarch.c:4252: internal-error: 
 > gdbarch: gdbarch_extract_return_value invalid
 > 
 > 
 > Andrew
 > 

I have an x86_64 machine I can try this on as well. It will have to be later
today though.

elena

regcache (Re: GDB respin)

[Michal Ludvig]

Andrew Cagney wrote:
> Can someone post backtraces?
> 
>      49    gdb.log:../../gdb-head/gdb/sentinel-frame.c:102: 
> internal-error: Function sentinal_frame_pop called
> 
> Er, this should shouldn't happen.  Backtrace?
> 
>       3    gdb.log:../../gdb-head/gdb/regcache.c:713: internal-error: 
> regcache_raw_read: Assertion `regcache != NULL && buf != NULL' failed.
> 
> Again, the caller is pretty messed up.
> 
>       5    gdb.log:../../gdb-head/gdb/gdbarch.c:4271: internal-error: 
> gdbarch: gdbarch_store_return_value invalid
>       2    gdb.log:&"../../gdb-head/gdb/gdbarch.c:4252: internal-error: 
> gdbarch: gdbarch_extract_return_value invalid\n"
>       6    gdb.log:../../gdb-head/gdb/gdbarch.c:4252: internal-error: 
> gdbarch: gdbarch_extract_return_value invalid

The problem on x86-64 is probably caused by the regbuf vs. regcache 
usage. This is a part of the patch that broke the testsuite:

diff -u -p -r1.33 -r1.34
--- gdb/x86-64-tdep.c   26 Oct 2002 10:37:45 -0000      1.33
+++ gdb/x86-64-tdep.c   26 Oct 2002 16:56:34 -0000      1.34
@@ -925,11 +925,35 @@ x86_64_init_abi (struct gdbarch_info inf
+  set_gdbarch_long_double_bit (gdbarch, 128);
+  set_gdbarch_ps_regnum (gdbarch, 17); /* %eflags */
+  set_gdbarch_stab_reg_to_regnum (gdbarch, x86_64_dwarf2_reg_to_regnum);
+  set_gdbarch_dwarf_reg_to_regnum (gdbarch, x86_64_dwarf2_reg_to_regnum);
+  set_gdbarch_extract_return_value (gdbarch, NULL);
+  set_gdbarch_store_return_value (gdbarch, NULL);
+  set_gdbarch_extract_struct_value_address (gdbarch, NULL);

If I comment out last three lines (those return_value related), the 
testsuite performs much better. But all the other lines seem have some 
influence on the results.

I'm about to convert x86-64 target to use regcache, but am not sure what 
must be done for it. Could someone please briefly explain me what is 
regcache all about and what must be changed in order to have the target 
regcache-compilant?

As I was looking to the sources I believe, that only 
x86_64_store_return_value() and x86_64_extract_return_value() must be 
modified. Am I right or not?

Thanks.

Michal Ludvig
-- 
* SuSE CR, s.r.o     * mludvig@suse.cz
* (+420) 296.545.373 * http://www.suse.cz

Re: regcache (Re: GDB respin)

[Andrew Cagney]

> diff -u -p -r1.33 -r1.34
> --- gdb/x86-64-tdep.c   26 Oct 2002 10:37:45 -0000      1.33
> +++ gdb/x86-64-tdep.c   26 Oct 2002 16:56:34 -0000      1.34
> @@ -925,11 +925,35 @@ x86_64_init_abi (struct gdbarch_info inf
> +  set_gdbarch_long_double_bit (gdbarch, 128);
> +  set_gdbarch_ps_regnum (gdbarch, 17); /* %eflags */
> +  set_gdbarch_stab_reg_to_regnum (gdbarch, x86_64_dwarf2_reg_to_regnum);
> +  set_gdbarch_dwarf_reg_to_regnum (gdbarch, x86_64_dwarf2_reg_to_regnum);
> +  set_gdbarch_extract_return_value (gdbarch, NULL);
> +  set_gdbarch_store_return_value (gdbarch, NULL);
> +  set_gdbarch_extract_struct_value_address (gdbarch, NULL);
> 
> If I comment out last three lines (those return_value related), the testsuite performs much better. But all the other lines seem have some influence on the results.

Hmm, at least extract_return_value shouldn't be set to NULL.  It should 
be doing:
	extract-return-value()
	-> legacy-extract-return-value()
	-> deprecated-extract-return-value()
	-> x86-64-extract-return-value
So I'd at least remove the setting of that one.  Since it is trying to 
restore the default, try setting it to legacy_...().  Same goes for 
store_return_value.  I think extract_struct_value_address is puzzling 
but ok.

> I'm about to convert x86-64 target to use regcache, but am not sure what must be done for it. Could someone please briefly explain me what is regcache all about and what must be changed in order to have the target regcache-compilant?

Where previously the code wrote (directly or implicitly) to a global 
buffer, it how is given an explicit object (the regcache).

You can use any *cooked*{read,write}* function you want in regcache.h. 
Typically the transformation is very direct: write_register() -> 
regcache_cooked_write().

> As I was looking to the sources I believe, that only x86_64_store_return_value() and x86_64_extract_return_value() must be modified. Am I right or not?

Per above, yes, I think this is correct.  Thanks!

Andrew

[PATCH] Re: regcache (Re: GDB respin)

[Mark Kettenis]

   Date: Thu, 06 Feb 2003 13:14:16 -0500
   From: Andrew Cagney <ac131313@redhat.com>

   > diff -u -p -r1.33 -r1.34
   > --- gdb/x86-64-tdep.c   26 Oct 2002 10:37:45 -0000      1.33
   > +++ gdb/x86-64-tdep.c   26 Oct 2002 16:56:34 -0000      1.34
   > @@ -925,11 +925,35 @@ x86_64_init_abi (struct gdbarch_info inf
   > +  set_gdbarch_long_double_bit (gdbarch, 128);
   > +  set_gdbarch_ps_regnum (gdbarch, 17); /* %eflags */
   > +  set_gdbarch_stab_reg_to_regnum (gdbarch, x86_64_dwarf2_reg_to_regnum);
   > +  set_gdbarch_dwarf_reg_to_regnum (gdbarch, x86_64_dwarf2_reg_to_regnum);
   > +  set_gdbarch_extract_return_value (gdbarch, NULL);
   > +  set_gdbarch_store_return_value (gdbarch, NULL);
   > +  set_gdbarch_extract_struct_value_address (gdbarch, NULL);
   > 
   > If I comment out last three lines (those return_value related), the testsuite performs much better. But all the other lines seem have some influence on the results.

   Hmm, at least extract_return_value shouldn't be set to NULL.  It should 
   be doing:
	   extract-return-value()
	   -> legacy-extract-return-value()
	   -> deprecated-extract-return-value()
	   -> x86-64-extract-return-value
   So I'd at least remove the setting of that one.  Since it is trying to 
   restore the default, try setting it to legacy_...().  Same goes for 
   store_return_value.  I think extract_struct_value_address is puzzling 
   but ok.

Looks like I screwed up by assuming that setting things to NULL would
make us invoke the default.  Although I'd encourage Ludvig to make
these functions regcache aware, I checked in the attached patch.  I
think it would be a good idea to have things working correctly before
starting the conversion.

Mark

Index: ChangeLog
from  Mark Kettenis  <kettenis@gnu.org>

	* x86-64-tdep.c (x86_64_init_abi): Set extract_return_value to
	legacy_extract_return_value and store_return_value to
	legacy_return_value.

Index: x86-64-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/x86-64-tdep.c,v
retrieving revision 1.46
diff -u -p -r1.46 x86-64-tdep.c
--- x86-64-tdep.c 5 Jan 2003 14:07:03 -0000 1.46
+++ x86-64-tdep.c 6 Feb 2003 23:20:18 -0000
@@ -980,7 +980,7 @@ x86_64_init_abi (struct gdbarch_info inf
   set_gdbarch_read_fp (gdbarch, cfi_read_fp);
 
   /* FIXME: kettenis/20021026: Should be undeprecated.  */
-  set_gdbarch_extract_return_value (gdbarch, NULL);
+  set_gdbarch_extract_return_value (gdbarch, legacy_extract_return_value);
   set_gdbarch_deprecated_extract_return_value (gdbarch,
 					       x86_64_extract_return_value);
   set_gdbarch_push_arguments (gdbarch, x86_64_push_arguments);
@@ -988,7 +988,7 @@ x86_64_init_abi (struct gdbarch_info inf
   set_gdbarch_pop_frame (gdbarch, x86_64_pop_frame);
   set_gdbarch_store_struct_return (gdbarch, x86_64_store_struct_return);
   /* FIXME: kettenis/20021026: Should be undeprecated.  */
-  set_gdbarch_store_return_value (gdbarch, NULL);
+  set_gdbarch_store_return_value (gdbarch, legacy_store_return_value);
   set_gdbarch_deprecated_store_return_value (gdbarch,
 					     x86_64_store_return_value);
   /* Override, since this is handled by x86_64_extract_return_value.  */

Re: regcache (Re: GDB respin)

[Michal Ludvig]

Andrew Cagney wrote:
> 
>> I'm about to convert x86-64 target to use regcache, but am not sure 
>> what must be done for it. Could someone please briefly explain me what 
>> is regcache all about and what must be changed in order to have the 
>> target regcache-compilant?
> 
> 
> Where previously the code wrote (directly or implicitly) to a global 
> buffer, it how is given an explicit object (the regcache).
> 
> You can use any *cooked*{read,write}* function you want in regcache.h. 
> Typically the transformation is very direct: write_register() -> 
> regcache_cooked_write().

What's the difference between cooked and non-cooked function? As far as 
I noticed, i386 target doesn't use cooked functions at all...

How do I store/read for example a long double, that is passed in two X87 
registers? With regbuf it's stored in a place for FP0 and FP0+8 in 
registers array. Will it come to a single slot of a regcache now?

Michal Ludvig
-- 
* SuSE CR, s.r.o     * mludvig@suse.cz
* (+420) 296.545.373 * http://www.suse.cz

Re: regcache (Re: GDB respin)

[Andrew Cagney]

> What's the difference between cooked and non-cooked function? As far as I noticed, i386 target doesn't use cooked functions at all...

Mumble something about long overdue documentation :-(

Cooked ~= user visible / ABI
Raw ~= underlying h/w / physical / ISA registers.

> How do I store/read for example a long double, that is passed in two X87 registers? With regbuf it's stored in a place for FP0 and FP0+8 in registers array. Will it come to a single slot of a regcache now?

Er, I thought the x87 FP registers were 12 bytes?  Anyway, if the value 
really is split across two FP registers then use two separate regcache 
writes.

Andrew

Re: regcache (Re: GDB respin)

[Michal Ludvig]

[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]

Michal Ludvig wrote:
>> I'm about to convert x86-64 target to use regcache, but am not sure 
>> what must be done for it. Could someone please briefly explain me what 
>> is regcache all about and what must be changed in order to have the 
>> target regcache-compilant?
> 
> Where previously the code wrote (directly or implicitly) to a global 
> buffer, it how is given an explicit object (the regcache).
> 
> You can use any *cooked*{read,write}* function you want in regcache.h. 
> Typically the transformation is very direct: write_register() -> 
> regcache_cooked_write().
> 
>> As I was looking to the sources I believe, that only 
>> x86_64_store_return_value() and x86_64_extract_return_value() must be 
>> modified. Am I right or not?
> 
> Per above, yes, I think this is correct.  Thanks!

OK, here is the first attempt to use regcache on x86-64 target.
As I run the testsuite on gdb-5.3 it made no difference on the results 
and I hope it will improve the mainline a little bit.

Is the patch OK to commit?

Michal Ludvig
-- 
* SuSE CR, s.r.o     * mludvig@suse.cz
* (+420) 296.545.373 * http://www.suse.cz

[-- Attachment #2: regcache-head-1.diff --]
[-- Type: text/plain, Size: 7058 bytes --]

2003-02-10  Michal Ludvig  <mludvig@suse.cz>

	* x86-64-tdep.c (x86_64_extract_return_value)
	(x86_64_store_return_value): Use regcache instead of regbuf.
	(x86_64_gdbarch_init): Change related set_gdbarch_* functions.
	* x86-64-linux-nat.c (fill_gregset): Use regcache.

Index: x86-64-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/x86-64-tdep.c,v
retrieving revision 1.47
diff -u -p -r1.47 x86-64-tdep.c
--- x86-64-tdep.c	6 Feb 2003 23:20:52 -0000	1.47
+++ x86-64-tdep.c	10 Feb 2003 21:20:20 -0000
@@ -559,7 +559,8 @@ x86_64_use_struct_convention (int gcc_p,
    into VALBUF.  */
 
 void
-x86_64_extract_return_value (struct type *type, char *regbuf, char *valbuf)
+x86_64_extract_return_value (struct type *type, struct regcache *regcache,
+			     void *valbuf)
 {
   enum x86_64_reg_class class[MAX_CLASSES];
   int n = classify_argument (type, class, 0);
@@ -576,7 +577,7 @@ x86_64_extract_return_value (struct type
       needed_intregs > RET_INT_REGS || needed_sseregs > RET_SSE_REGS)
     {				/* memory class */
       CORE_ADDR addr;
-      memcpy (&addr, regbuf, REGISTER_RAW_SIZE (RAX_REGNUM));
+      regcache_raw_read (regcache, RAX_REGNUM, &addr);
       read_memory (addr, valbuf, TYPE_LENGTH (type));
       return;
     }
@@ -590,41 +591,40 @@ x86_64_extract_return_value (struct type
 	    case X86_64_NO_CLASS:
 	      break;
 	    case X86_64_INTEGER_CLASS:
-	      memcpy (valbuf + offset,
-		      regbuf + REGISTER_BYTE (ret_int_r[(intreg + 1) / 2]),
-		      8);
+	      regcache_cooked_read (regcache, ret_int_r[(intreg + 1) / 2],
+				    (char *) valbuf + offset);
 	      offset += 8;
 	      intreg += 2;
 	      break;
 	    case X86_64_INTEGERSI_CLASS:
-	      memcpy (valbuf + offset,
-		      regbuf + REGISTER_BYTE (ret_int_r[intreg / 2]), 4);
+	      regcache_cooked_read_part (regcache, ret_int_r[intreg / 2],
+					 0, 4, (char *) valbuf + offset);
 	      offset += 8;
 	      intreg++;
 	      break;
 	    case X86_64_SSEDF_CLASS:
 	    case X86_64_SSESF_CLASS:
 	    case X86_64_SSE_CLASS:
-	      memcpy (valbuf + offset,
-		      regbuf + REGISTER_BYTE (ret_sse_r[(ssereg + 1) / 2]),
-		      8);
+	      regcache_cooked_read_part (regcache,
+					 ret_sse_r[(ssereg + 1) / 2], 0, 8,
+					 (char *) valbuf + offset);
 	      offset += 8;
 	      ssereg += 2;
 	      break;
 	    case X86_64_SSEUP_CLASS:
-	      memcpy (valbuf + offset + 8,
-		      regbuf + REGISTER_BYTE (ret_sse_r[ssereg / 2]), 8);
+	      regcache_cooked_read_part (regcache, ret_sse_r[ssereg / 2],
+					 0, 8, (char *) valbuf + offset);
 	      offset += 8;
 	      ssereg++;
 	      break;
 	    case X86_64_X87_CLASS:
-	      memcpy (valbuf + offset, regbuf + REGISTER_BYTE (FP0_REGNUM),
-		      8);
+	      regcache_cooked_read_part (regcache, FP0_REGNUM,
+					 0, 8, (char *) valbuf + offset);
 	      offset += 8;
 	      break;
 	    case X86_64_X87UP_CLASS:
-	      memcpy (valbuf + offset,
-		      regbuf + REGISTER_BYTE (FP0_REGNUM) + 8, 8);
+	      regcache_cooked_read_part (regcache, FP0_REGNUM,
+					 8, 2, (char *) valbuf + offset);
 	      offset += 8;
 	      break;
 	    case X86_64_MEMORY_CLASS:
@@ -749,7 +749,8 @@ x86_64_push_arguments (int nargs, struct
 /* Write into the appropriate registers a function return value stored
    in VALBUF of type TYPE, given in virtual format.  */
 void
-x86_64_store_return_value (struct type *type, char *valbuf)
+x86_64_store_return_value (struct type *type, struct regcache *regcache,
+			   const void *valbuf)
 {
   int len = TYPE_LENGTH (type);
 
@@ -760,8 +761,7 @@ x86_64_store_return_value (struct type *
 	  && TARGET_LONG_DOUBLE_FORMAT == &floatformat_i387_ext)
 	{
 	  /* Copy straight over.  */
-	  deprecated_write_register_bytes (REGISTER_BYTE (FP0_REGNUM), valbuf,
-					   FPU_REG_RAW_SIZE);
+	  regcache_cooked_write (regcache, FP0_REGNUM, valbuf);
 	}
       else
 	{
@@ -774,8 +774,8 @@ x86_64_store_return_value (struct type *
 	     it is the best we can do.  */
 	  val = extract_floating (valbuf, TYPE_LENGTH (type));
 	  floatformat_from_doublest (&floatformat_i387_ext, &val, buf);
-	  deprecated_write_register_bytes (REGISTER_BYTE (FP0_REGNUM), buf,
-					   FPU_REG_RAW_SIZE);
+	  regcache_cooked_write_part (regcache, FP0_REGNUM,
+			  	      0, FPU_REG_RAW_SIZE, buf);
 	}
     }
   else
@@ -784,13 +784,13 @@ x86_64_store_return_value (struct type *
       int high_size = REGISTER_RAW_SIZE (1);
 
       if (len <= low_size)
-	deprecated_write_register_bytes (REGISTER_BYTE (0), valbuf, len);
+        regcache_cooked_write_part (regcache, 0, 0, len, valbuf);
       else if (len <= (low_size + high_size))
 	{
-	  deprecated_write_register_bytes (REGISTER_BYTE (0), valbuf,
-					   low_size);
-	  deprecated_write_register_bytes (REGISTER_BYTE (1),
-					   valbuf + low_size, len - low_size);
+ 	  regcache_cooked_write_part (regcache, 0, 0, low_size, valbuf);
+ 	  regcache_cooked_write_part (regcache, 1, 0,
+ 				      len - low_size,
+ 				      (const char *) valbuf + low_size);
 	}
       else
 	internal_error (__FILE__, __LINE__,
@@ -979,18 +979,13 @@ x86_64_init_abi (struct gdbarch_info inf
   /* FIXME: kettenis/20021026: Should we set parm_boundary to 64 here?  */
   set_gdbarch_read_fp (gdbarch, cfi_read_fp);
 
-  /* FIXME: kettenis/20021026: Should be undeprecated.  */
-  set_gdbarch_extract_return_value (gdbarch, legacy_extract_return_value);
-  set_gdbarch_deprecated_extract_return_value (gdbarch,
-					       x86_64_extract_return_value);
+  set_gdbarch_extract_return_value (gdbarch, x86_64_extract_return_value);
+
   set_gdbarch_push_arguments (gdbarch, x86_64_push_arguments);
   set_gdbarch_push_return_address (gdbarch, x86_64_push_return_address);
   set_gdbarch_pop_frame (gdbarch, x86_64_pop_frame);
   set_gdbarch_store_struct_return (gdbarch, x86_64_store_struct_return);
-  /* FIXME: kettenis/20021026: Should be undeprecated.  */
-  set_gdbarch_store_return_value (gdbarch, legacy_store_return_value);
-  set_gdbarch_deprecated_store_return_value (gdbarch,
-					     x86_64_store_return_value);
+  set_gdbarch_store_return_value (gdbarch, x86_64_store_return_value);
   /* Override, since this is handled by x86_64_extract_return_value.  */
   set_gdbarch_extract_struct_value_address (gdbarch, NULL);
   set_gdbarch_use_struct_convention (gdbarch, x86_64_use_struct_convention);
Index: x86-64-linux-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/x86-64-linux-nat.c,v
retrieving revision 1.20
diff -u -p -r1.20 x86-64-linux-nat.c
--- x86-64-linux-nat.c	14 Jan 2003 00:49:04 -0000	1.20
+++ x86-64-linux-nat.c	10 Feb 2003 21:20:20 -0000
@@ -158,7 +158,7 @@ fill_gregset (elf_gregset_t * gregsetp, 
 
   for (i = 0; i < x86_64_num_gregs; i++)
     if ((regno == -1 || regno == i))
-      deprecated_read_register_gen (i, (char *) (regp + x86_64_regmap[i]));
+      regcache_collect (i, (char *) (regp + x86_64_regmap[i]));
 }
 
 /* Fetch all general-purpose registers from process/thread TID and

Re: regcache (Re: GDB respin)

[Mark Kettenis]

   Date: Mon, 10 Feb 2003 22:26:34 +0100
   From: Michal Ludvig <mludvig@suse.cz>

   OK, here is the first attempt to use regcache on x86-64 target.
   As I run the testsuite on gdb-5.3 it made no difference on the results 
   and I hope it will improve the mainline a little bit.

   Is the patch OK to commit?

If I understood Andrew correctly you should only use the cooked
functions here, so the line

    regcache_raw_read (regcache, RAX_REGNUM, &addr);

should read

    regcahce_cooked_read (regcache, RAX_REGNUM, &addr);

With that change, this is OK.

Thanks,

Mark

Re: regcache (Re: GDB respin)

[Andrew Cagney]

> If I understood Andrew correctly you should only use the cooked
> functions here, so the line
> 
>     regcache_raw_read (regcache, RAX_REGNUM, &addr);
> 
> should read
> 
>     regcahce_cooked_read (regcache, RAX_REGNUM, &addr);
> 
> With that change, this is OK.
> 
> Thanks,

Ditto from me, Michael, thanks for cleaning this up.

Andrew

Re: regcache (Re: GDB respin)

[Michal Ludvig]

Andrew Cagney wrote:
> 
>> If I understood Andrew correctly you should only use the cooked
>> functions here, so the line
>>
>>     regcache_raw_read (regcache, RAX_REGNUM, &addr);
>> should read
>>     regcahce_cooked_read (regcache, RAX_REGNUM, &addr);
>> With that change, this is OK.
> 
> Ditto from me, Michael, thanks for cleaning this up.
> 
> Andrew

Committed with the above change. Thanks!

Anyway there is still 440 errors in mainline vs. 196 in 5.3 on x86-64. 
Hopefully I'll get rid of most of them when the sentinel-problem is 
solved. I'll look on it tomorrow.

Michal Ludvig
-- 
* SuSE CR, s.r.o     * mludvig@suse.cz
* (+420) 296.545.373 * http://www.suse.cz