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

Re: GDB respin

[Michael Elizabeth Chastain]

Hi Michal,
> After merging i386 and x86-64 we need some more time to make HEAD at 
> least as stable as 5.3 is. For now too many testsuites fail in HEAD.

Can you give more detail on that?  Which platforms are you seeing
testsuite trouble with?

On native i686-pc-linux-gnu, my test suite results have few new
problems from 5.3 to HEAD.

Michael C

Re: GDB respin

[Michael Elizabeth Chastain]

> In fact, if the console problem can be resolved, I think there is a very 
> strong incentive to quickly spin out a 5.4.

Okay, on my next spin I will go through the 'Compare by GDB' table and
chase down all the differences and write a report on 5.3 versus HEAD.

My recollection is that there aren't any serious problems, at least in
the parts I cover.  Which is like saying that New York City doesn't have
a serious crime problem in the area between 40th and 60th streets and
3rd and 8th avenues.  :)

gdb.base/testsuite and gdb.c++/testsuite have no gdb regressions between
5.3 and 2003-01-20.

There are some new tests in gdb.base/advance.exp and gdb.base/until.exp
that FAIL with gcc v3, but that is a problem with the tests rather than
gdb.  Briefly, after the return from a call to 'foo();', the current
line might be on line N or on line N+1 depending on the compiler, but
the test script always expects to be on line N.  The cheesy way out
would be to change the program-under-test to 'foo(), bar();' with a
comma operator to force a sequence point.

One issue is that all the MI tests got shuffled so that every MI
non-PASS might be a regression or might not be.  Someone has to look at
the MI results on four configurations (gcc v2/v3 and dwarf-2/stabs+) and
say whether they are must-fix or not.

Michael C

Re: GDB respin

[Michael Elizabeth Chastain]

[I'm partially back.  I can read my mail, and I can run my test bed,
 but I'm not caught up on stuff.  -- Michael C]

Andrew Cagney asks:
> Should there be a 5.3.1.  So far not much has been comitted to the 
> branch.  However, there have been a number of configure / build bug reports.

My preference would be to not produce 5.3.1.  It seems like a low-yield
use of resources to me.

Are the configure/build problems fixed in HEAD?

For those problems which are not fixed in HEAD:
  we need to do that anyways, no matter what

For those problems which are fixed in HEAD:
  ask the bug report submitters to try a HEAD snapshot
  put the PR's into 'FEEDBACK' state

Anyways, I will keep testing and reporting on gdb_5_3-branch.
My test bed role is separate from my loudmouth role.

Michael C

Re: GDB respin

[Andrew Cagney]

> [I'm partially back.  I can read my mail, and I can run my test bed,
>  but I'm not caught up on stuff.  -- Michael C]
> 
> Andrew Cagney asks:
> 
>> Should there be a 5.3.1.  So far not much has been comitted to the 
>> branch.  However, there have been a number of configure / build bug reports.
> 
> 
> My preference would be to not produce 5.3.1.  It seems like a low-yield
> use of resources to me.
> 
> Are the configure/build problems fixed in HEAD?

No.  Check the bug database for `high' priority `build' problems.

> For those problems which are not fixed in HEAD:
>   we need to do that anyways, no matter what
> 
> For those problems which are fixed in HEAD:
>   ask the bug report submitters to try a HEAD snapshot
>   put the PR's into 'FEEDBACK' state
> 
> Anyways, I will keep testing and reporting on gdb_5_3-branch.
> My test bed role is separate from my loudmouth role.

:-)

In fact, if the console problem can be resolved, I think there is a very 
strong incentive to quickly spin out a 5.4.

Andrew

Re: GDB respin

[Quality Quorum]

On Thu, 30 Jan 2003, Andrew Cagney wrote:

> In fact, if the console problem can be resolved, I think there is a very
> strong incentive to quickly spin out a 5.4.

Releases are multiplied like rabbits :). If we are going thorugh big
releases anyway, it may seem cost effective to refactor gdb into C++, using
the real thing would save a lot of time in the long run comparing
with constant grappling with poor man's c++.

> Andrew

Thanks,

Aleksey

Re: GDB respin

[Michal Ludvig]

Andrew Cagney wrote:

> I think there is a very 
> strong incentive to quickly spin out a 5.4.

After merging i386 and x86-64 we need some more time to make HEAD at 
least as stable as 5.3 is. For now too many testsuites fail in HEAD.

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

GDB respin

[Andrew Cagney]

Hello,

Should there be a 5.3.1.  So far not much has been comitted to the 
branch.  However, there have been a number of configure / build bug reports.

If nothing else, I'll raise this question again in a month and then 
declare the branch dead.

Andrew