PATCH: Start Fortran support for variable objects.

PATCH: Start Fortran support for variable objects.

[Nick Roberts]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 1455 bytes --]


This patch adjusts the offset from 0 to 1 to allow the display of arrays
in Fortran using variable objects.

Currently given:

      DIMENSION I(4)
      DATA I/1,2,3,4/

(gdb)
-var-create - * I
^done,name="var1",numchild="4",type="integer (4)"
(gdb) 
-var-list-children var1
&"warning: array or string index out of range\n"
^done,numchild="4",children={child={name="var1.0",exp="0",numchild="0",type="integer"},child={name="var1.1",exp="1",numchild="0",type="integer"},child={name="var1.2",exp="2",numchild="0",type="integer"},child={name="var1.3",exp="3",numchild="0",type="integer"}}
(gdb) 

This patch changes the output to:

(gdb) 
-var-create - * I
^done,name="var1",numchild="4",type="integer (4)"
(gdb) 
-var-list-children var1
^done,numchild="4",children=[child={name="var1.1",exp="1",numchild="0",type="integer"},child={name="var1.2",exp="2",numchild="0",type="integer"},child={name="var1.3",exp="3",numchild="0",type="integer"},child={name="var1.4",exp="4",numchild="0",type="integer"}]
(gdb) 

It doesn't add any new methods for finding values in Fortran but allows for
this to be done later (hopefully someone else will pick this up).

It should be safe to apply as it doesn't change behaviour for existing
languages.

In addition to the patch below, I attach the watch windows from my mode
(gdb-ui.el) in Emacs 22.0.50 (in CVS) for Fortran and C to show the different
offsets.  gdb-mi.el in the GDB repository would work similarly.

Nick



[-- Attachment #2: Fortran watch window --]
[-- Type: image/png, Size: 3205 bytes --]

[-- Attachment #3: C watch window --]
[-- Type: image/png, Size: 3573 bytes --]

[-- Attachment #4: message body text --]
[-- Type: text/plain, Size: 3481 bytes --]



2005-06-30  Nick Roberts  <nickrob@snap.net.nz>

	* varobj.h: Add Fortran to list of supported languages.

	* varobj.c (varobj_language_string, variable_language): Add Fortran.
	(languages) Add Fortran.  Use c methods.
	(varobj_list_children): Adjust offset for Fortran.


*** varobj.h.~1.4.~	2001-08-18 06:56:49.000000000 +1200
--- varobj.h	2005-06-29 15:43:31.000000000 +1200
***************
*** 45,51 ****
  /* Languages supported by this variable objects system. */
  enum varobj_languages
    {
!     vlang_unknown = 0, vlang_c, vlang_cplus, vlang_java, vlang_end
    };
  
  /* String representations of gdb's known languages (defined in varobj.c) */
--- 45,52 ----
  /* Languages supported by this variable objects system. */
  enum varobj_languages
    {
!     vlang_unknown = 0, vlang_c, vlang_cplus, vlang_java,  vlang_fortran,
!     vlang_end
    };
  
  /* String representations of gdb's known languages (defined in varobj.c) */


*** varobj.c.~1.54.~	2005-06-29 00:28:57.000000000 +1200
--- varobj.c	2005-06-29 17:35:34.000000000 +1200
***************
*** 46,52 ****
    { "natural", "binary", "decimal", "hexadecimal", "octal" };
  
  /* String representations of gdb's known languages */
! char *varobj_language_string[] = { "unknown", "C", "C++", "Java" };
  
  /* Data structures */
  
--- 46,52 ----
    { "natural", "binary", "decimal", "hexadecimal", "octal" };
  
  /* String representations of gdb's known languages */
! char *varobj_language_string[] = { "unknown", "C", "C++", "Java", "Fortran" };
  
  /* Data structures */
  
***************
*** 372,377 ****
--- 372,389 ----
     java_type_of_child,
     java_variable_editable,
     java_value_of_variable}
+   ,
+   /* Fortran */
+   {
+    vlang_fortran,
+    c_number_of_children,
+    c_name_of_variable,
+    c_name_of_child,
+    c_value_of_root,
+    c_value_of_child,
+    c_type_of_child,
+    c_variable_editable,
+    c_value_of_variable}
  };
  
  /* A little convenience enum for dealing with C++/Java */
***************
*** 696,702 ****
  {
    struct varobj *child;
    char *name;
!   int i;
  
    /* sanity check: have we been passed a pointer? */
    if (childlist == NULL)
--- 708,714 ----
  {
    struct varobj *child;
    char *name;
!   int i, j;
  
    /* sanity check: have we been passed a pointer? */
    if (childlist == NULL)
***************
*** 715,725 ****
        /* Mark as the end in case we bail out */
        *((*childlist) + i) = NULL;
  
        /* check if child exists, if not create */
!       name = name_of_child (var, i);
        child = child_exists (var, name);
        if (child == NULL)
! 	child = create_child (var, i, name);
  
        *((*childlist) + i) = child;
      }
--- 727,742 ----
        /* Mark as the end in case we bail out */
        *((*childlist) + i) = NULL;
  
+       if (variable_language (var) == vlang_fortran)
+ 	j = i + 1;
+       else
+ 	j = i;
+ 
        /* check if child exists, if not create */
!       name = name_of_child (var, j);
        child = child_exists (var, name);
        if (child == NULL)
! 	child = create_child (var, j, name);
  
        *((*childlist) + i) = child;
      }
***************
*** 1564,1570 ****
      case language_java:
        lang = vlang_java;
        break;
!     }
  
    return lang;
  }
--- 1581,1590 ----
      case language_java:
        lang = vlang_java;
        break;
!     case language_fortran:
!       lang = vlang_fortran;
!       break;
!      }
  
    return lang;
  }

Re: PATCH: Start Fortran support for variable objects.

[Daniel Jacobowitz]

On Thu, Jun 30, 2005 at 09:29:16AM +1200, Nick Roberts wrote:
> 
> This patch adjusts the offset from 0 to 1 to allow the display of arrays
> in Fortran using variable objects.

I see that you're hardcoding this based on language.  Can we do it
based on type instead?  Specifically, TYPE_LOW_BOUND and
TYPE_HIGH_BOUND.  We have got type information here - unless I'm
misreading, var->type should be the type of the array.

I'm not thrilled with the existing language-dependent behavior in
varobj; we have got a common type system, after all.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: PATCH: Start Fortran support for variable objects.

[Nick Roberts]

Daniel Jacobowitz writes:
 > On Thu, Jun 30, 2005 at 09:29:16AM +1200, Nick Roberts wrote:
 > > 
 > > This patch adjusts the offset from 0 to 1 to allow the display of arrays
 > > in Fortran using variable objects.
 > 
 > I see that you're hardcoding this based on language.  Can we do it
 > based on type instead?  Specifically, TYPE_LOW_BOUND and
 > TYPE_HIGH_BOUND.  We have got type information here - unless I'm
 > misreading, var->type should be the type of the array.

They look pretty similar to me.

C:

(top-gdb) p TYPE_LOW_BOUND(var->type)
$18 = 0
(top-gdb) p* var->type->main_type
$33 = {code = TYPE_CODE_ARRAY, upper_bound_type = BOUND_SIMPLE, 
  lower_bound_type = BOUND_SIMPLE, name = 0x0, tag_name = 0x0, 
  objfile = 0x8357618, target_type = 0x8372c74, flags = 0, nfields = 1, 
  vptr_fieldno = -1, fields = 0x837496c, vptr_basetype = 0x0, type_specific = {
    cplus_stuff = 0x0, floatformat = 0x0}}

Fortran:

(top-gdb) p TYPE_LOW_BOUND(var->type)
$3 = 0
(top-gdb) p* var->type->main_type
$8 = {code = TYPE_CODE_ARRAY, upper_bound_type = BOUND_SIMPLE, 
  lower_bound_type = BOUND_SIMPLE, name = 0x0, tag_name = 0x0, 
  objfile = 0x8357618, target_type = 0x83654cc, flags = 0, nfields = 1, 
  vptr_fieldno = -1, fields = 0x83655c4, vptr_basetype = 0x0, 
  type_specific = {cplus_stuff = 0x0, floatformat = 0x0}}

I need more of a clue to follow your suggestion.

 > I'm not thrilled with the existing language-dependent behavior in
 > varobj; we have got a common type system, after all.

At the moment, I'm finding it hard enough to just work with whats already
there.  Maybe later on I'll be able to step up another gear.

Nick

Re: PATCH: Start Fortran support for variable objects.

[Daniel Jacobowitz]

On Thu, Jun 30, 2005 at 09:02:34PM +1200, Nick Roberts wrote:
> Daniel Jacobowitz writes:
>  > On Thu, Jun 30, 2005 at 09:29:16AM +1200, Nick Roberts wrote:
>  > > 
>  > > This patch adjusts the offset from 0 to 1 to allow the display of arrays
>  > > in Fortran using variable objects.
>  > 
>  > I see that you're hardcoding this based on language.  Can we do it
>  > based on type instead?  Specifically, TYPE_LOW_BOUND and
>  > TYPE_HIGH_BOUND.  We have got type information here - unless I'm
>  > misreading, var->type should be the type of the array.
> 
> They look pretty similar to me.
> 
> C:
> 
> (top-gdb) p TYPE_LOW_BOUND(var->type)
> $18 = 0
> (top-gdb) p* var->type->main_type
> $33 = {code = TYPE_CODE_ARRAY, upper_bound_type = BOUND_SIMPLE, 
>   lower_bound_type = BOUND_SIMPLE, name = 0x0, tag_name = 0x0, 
>   objfile = 0x8357618, target_type = 0x8372c74, flags = 0, nfields = 1, 
>   vptr_fieldno = -1, fields = 0x837496c, vptr_basetype = 0x0, type_specific = {
>     cplus_stuff = 0x0, floatformat = 0x0}}
> 
> Fortran:
> 
> (top-gdb) p TYPE_LOW_BOUND(var->type)
> $3 = 0
> (top-gdb) p* var->type->main_type
> $8 = {code = TYPE_CODE_ARRAY, upper_bound_type = BOUND_SIMPLE, 
>   lower_bound_type = BOUND_SIMPLE, name = 0x0, tag_name = 0x0, 
>   objfile = 0x8357618, target_type = 0x83654cc, flags = 0, nfields = 1, 
>   vptr_fieldno = -1, fields = 0x83655c4, vptr_basetype = 0x0, 
>   type_specific = {cplus_stuff = 0x0, floatformat = 0x0}}
> 
> I need more of a clue to follow your suggestion.

Well, that's what was SUPPOSED to happen, anyway.

 <1><a52>: Abbrev Number: 4 (DW_TAG_array_type)
     DW_AT_sibling     : <a62>  
     DW_AT_type        : <a62>  
 <2><a5b>: Abbrev Number: 5 (DW_TAG_subrange_type)
     DW_AT_type        : <a62>  
     DW_AT_upper_bound : 4      

I would have expected there to be a lower bound also... but there just
isn't.  Your patch is more or less OK.  Let me reply to it to pick up
some formatting comments.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: PATCH: Start Fortran support for variable objects.

[Daniel Jacobowitz]

On Thu, Jun 30, 2005 at 09:29:16AM +1200, Nick Roberts wrote:
> !     vlang_unknown = 0, vlang_c, vlang_cplus, vlang_java,  vlang_fortran,
> !     vlang_end

Extra space before vlang_fortran.

>      java_value_of_variable}
> +   ,
> +   /* Fortran */

This style's wacky, but it's already in the file, so that's fine.

> --- 727,742 ----
>         /* Mark as the end in case we bail out */
>         *((*childlist) + i) = NULL;
>   
> +       if (variable_language (var) == vlang_fortran)
> + 	j = i + 1;
> +       else
> + 	j = i;
> + 
>         /* check if child exists, if not create */
> !       name = name_of_child (var, j);
>         child = child_exists (var, name);
>         if (child == NULL)
> ! 	child = create_child (var, j, name);
>   
>         *((*childlist) + i) = child;
>       }

Do you think you should use f77_get_dynamic_lowerbound?  See eval.c,
under multi_f77_subscript.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: PATCH: Start Fortran support for variable objects.

[Nick Roberts]

 > Well, that's what was SUPPOSED to happen, anyway.
 > 
 >  <1><a52>: Abbrev Number: 4 (DW_TAG_array_type)
 >      DW_AT_sibling     : <a62>  
 >      DW_AT_type        : <a62>  
 >  <2><a5b>: Abbrev Number: 5 (DW_TAG_subrange_type)
 >      DW_AT_type        : <a62>  
 >      DW_AT_upper_bound : 4      

This is Dwarf output? Using something like readelf? (I'm just guessing).
 
 > I would have expected there to be a lower bound also... but there just
 > isn't.  Your patch is more or less OK.  Let me reply to it to pick up
 > some formatting comments.

For future reference, are you saying that there should be some internal
representation for arrays that GDB uses which should describe the offset;
that this could be used to print the variable object without reference
to the language; and that this method should work with other unsupported
(by varobj.c) languages like Pascal, for example?

Nick

Re: PATCH: Start Fortran support for variable objects.

[Nick Roberts]

Daniel Jacobowitz writes:
 > On Thu, Jun 30, 2005 at 09:29:16AM +1200, Nick Roberts wrote:
 > > !     vlang_unknown = 0, vlang_c, vlang_cplus, vlang_java,  vlang_fortran,
 > > !     vlang_end
 > 
 > Extra space before vlang_fortran.

OK

...
 > > --- 727,742 ----
 > >         /* Mark as the end in case we bail out */
 > >         *((*childlist) + i) = NULL;
 > >   
 > > +       if (variable_language (var) == vlang_fortran)
 > > + 	j = i + 1;
 > > +       else
 > > + 	j = i;
 > > + 
 > >         /* check if child exists, if not create */
 > > !       name = name_of_child (var, j);
 > >         child = child_exists (var, name);
 > >         if (child == NULL)
 > > ! 	child = create_child (var, j, name);
 > >   
 > >         *((*childlist) + i) = child;
 > >       }
 > 
 > Do you think you should use f77_get_dynamic_lowerbound?  See eval.c,
 > under multi_f77_subscript.

As in the patch below?  I don't understand the extra cases it appears to
cover, but it worked for the tests I tried.

Nick


*** varobj.c.~1.54.~	2005-06-29 00:28:57.000000000 +1200
--- varobj.c	2005-07-01 10:06:44.000000000 +1200
***************
*** 23,28 ****
--- 23,29 ----
  #include "expression.h"
  #include "frame.h"
  #include "language.h"
+ #include "f-lang.h"
  #include "wrapper.h"
  #include "gdbcmd.h"
  
***************
*** 46,52 ****
    { "natural", "binary", "decimal", "hexadecimal", "octal" };
  
  /* String representations of gdb's known languages */
! char *varobj_language_string[] = { "unknown", "C", "C++", "Java" };
  
  /* Data structures */
  
--- 47,53 ----
    { "natural", "binary", "decimal", "hexadecimal", "octal" };
  
  /* String representations of gdb's known languages */
! char *varobj_language_string[] = { "unknown", "C", "C++", "Java", "Fortran" };
  
  /* Data structures */
  
***************
*** 372,377 ****
--- 373,390 ----
     java_type_of_child,
     java_variable_editable,
     java_value_of_variable}
+   ,
+   /* Fortran */
+   {
+    vlang_fortran,
+    c_number_of_children,
+    c_name_of_variable,
+    c_name_of_child,
+    c_value_of_root,
+    c_value_of_child,
+    c_type_of_child,
+    c_variable_editable,
+    c_value_of_variable}
  };
  
  /* A little convenience enum for dealing with C++/Java */
***************
*** 696,702 ****
  {
    struct varobj *child;
    char *name;
!   int i;
  
    /* sanity check: have we been passed a pointer? */
    if (childlist == NULL)
--- 709,716 ----
  {
    struct varobj *child;
    char *name;
!   int lower_bound;
!   int i, j, retcode;
  
    /* sanity check: have we been passed a pointer? */
    if (childlist == NULL)
***************
*** 715,725 ****
        /* Mark as the end in case we bail out */
        *((*childlist) + i) = NULL;
  
        /* check if child exists, if not create */
!       name = name_of_child (var, i);
        child = child_exists (var, name);
        if (child == NULL)
! 	child = create_child (var, i, name);
  
        *((*childlist) + i) = child;
      }
--- 729,750 ----
        /* Mark as the end in case we bail out */
        *((*childlist) + i) = NULL;
  
+       if (variable_language (var) == vlang_fortran)
+ 	{
+ 	  retcode = f77_get_dynamic_lowerbound (var->type, &lower_bound);
+ 	  if (retcode == BOUND_FETCH_ERROR)
+ 	    error (_("Cannot obtain valid array lower bound"));
+ 	  else
+ 	    j = i + lower_bound;
+ 	}
+       else
+ 	j = i;
+ 
        /* check if child exists, if not create */
!       name = name_of_child (var, j);
        child = child_exists (var, name);
        if (child == NULL)
! 	child = create_child (var, j, name);
  
        *((*childlist) + i) = child;
      }
***************
*** 1564,1570 ****
      case language_java:
        lang = vlang_java;
        break;
!     }
  
    return lang;
  }
--- 1589,1598 ----
      case language_java:
        lang = vlang_java;
        break;
!     case language_fortran:
!       lang = vlang_fortran;
!       break;
!      }
  
    return lang;
  }

Re: PATCH: Start Fortran support for variable objects.

[Daniel Jacobowitz]

On Fri, Jul 01, 2005 at 09:24:17AM +1200, Nick Roberts wrote:
>  > Well, that's what was SUPPOSED to happen, anyway.
>  > 
>  >  <1><a52>: Abbrev Number: 4 (DW_TAG_array_type)
>  >      DW_AT_sibling     : <a62>  
>  >      DW_AT_type        : <a62>  
>  >  <2><a5b>: Abbrev Number: 5 (DW_TAG_subrange_type)
>  >      DW_AT_type        : <a62>  
>  >      DW_AT_upper_bound : 4      
> 
> This is Dwarf output? Using something like readelf? (I'm just guessing).

That's right.

>  > I would have expected there to be a lower bound also... but there just
>  > isn't.  Your patch is more or less OK.  Let me reply to it to pick up
>  > some formatting comments.
> 
> For future reference, are you saying that there should be some internal
> representation for arrays that GDB uses which should describe the offset;
> that this could be used to print the variable object without reference
> to the language; and that this method should work with other unsupported
> (by varobj.c) languages like Pascal, for example?

I'd like that.  Varobj shouldn't need to know this; the rest of GDB
should be able to provide it.  But that's just my design instinct
speaking.  It may not be worth the trouble putting all the pieces
together.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: PATCH: Start Fortran support for variable objects.

[Wu Zhou]

Hi, Nick and Daniel

I have two comments below, hope that they might be helpful.  Thanks.

On Fri, 1 Jul 2005, Nick Roberts wrote:

> As in the patch below?  I don't understand the extra cases it appears to
> cover, but it worked for the tests I tried.

Maybe it is also helpful to test against such arrays definition as:
  
  integer array(0:5), integer array(-1:4)

or even
  
  integer array(0:5,-1:4)

(if variable object does support multi-dimension array. I don't know much 
about variable object, and MI as a whole.)

The second comment is about the following text in a former mail Nick sent: 

> Fortran:
> 
> (top-gdb) p TYPE_LOW_BOUND(var->type)
> $3 = 0
> (top-gdb) p* var->type->main_type
> $8 = {code = TYPE_CODE_ARRAY, upper_bound_type = BOUND_SIMPLE, 
>  lower_bound_type = BOUND_SIMPLE, name = 0x0, tag_name = 0x0, 
>  objfile = 0x8357618, target_type = 0x83654cc, flags = 0, nfields = 1, 
>  vptr_fieldno = -1, fields = 0x83655c4, vptr_basetype = 0x0, 
>  type_specific = {cplus_stuff = 0x0, floatformat = 0x0}}

For Fortran array such as DIMENSION I(4), the lower bound should be 1 by
default.  The following session on my box shows this:

<top-gdb> p type->main_type->fields->type->main_type->fields[0].loc.bitpos
$3 = 1
<top-gdb> p type->main_type->fields->type->main_type->fields[1].loc.bitpos
$4 = 4

I guess there might be some errors in the process of creating varobj for 
Fortran array.  

Anyway it is just my guess.  If the patch works ok with different kinds of 
array definitions, it should be okay.  

Cheers
- Wu Zhou

Re: PATCH: Start Fortran support for variable objects.

[Nick Roberts]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 2300 bytes --]

 > I have two comments below, hope that they might be helpful.  Thanks.
 > 
 > On Fri, 1 Jul 2005, Nick Roberts wrote:
 > 
 > > As in the patch below?  I don't understand the extra cases it appears to
 > > cover, but it worked for the tests I tried.
 > 
 > Maybe it is also helpful to test against such arrays definition as:
 >   
 >   integer array(0:5), integer array(-1:4)
 > 
 > or even
 >   
 >   integer array(0:5,-1:4)
 >
 > (if variable object does support multi-dimension array. I don't know much 
 > about variable object, and MI as a whole.)

Ah!  I see now.  I've not used such arrays in Fortran.  Using

      INTEGER ARRAY1(0:5), ARRAY2(-1:4)
      INTEGER ARRAY3(0:2,-1:1)
      DATA ARRAY1/1,2,3,4,5,6/
      DATA ARRAY2/1,2,3,4,5,6/
      DATA ARRAY3/11,21,31,12,22,32,13,23,33/

the latest patch seems to work (see attached image below).  I am sure
that my original patch would have failed for these cases.

 > The second comment is about the following text in a former mail Nick sent: 
 > 
 > > Fortran:
 > > 
 > > (top-gdb) p TYPE_LOW_BOUND(var->type)
 > > $3 = 0
 ...
 > 
 > For Fortran array such as DIMENSION I(4), the lower bound should be 1 by
 > default.  The following session on my box shows this:
 > 
 > <top-gdb> p type->main_type->fields->type->main_type->fields[0].loc.bitpos
 > $3 = 1
 > <top-gdb> p type->main_type->fields->type->main_type->fields[1].loc.bitpos
 > $4 = 4

So I should have done:

(top-gdb) p TYPE_LOW_BOUND(var->type->main_type->fields->type)
$1 = 1
(top-gdb) p TYPE_HIGH_BOUND(var->type->main_type->fields->type)
$2 = 4

 > I guess there might be some errors in the process of creating varobj for 
 > Fortran array.  

No the information seems to be there.  So maybe:

  for (i = 0; i < var->num_children; i++)
    {
      /* Mark as the end in case we bail out */
      *((*childlist) + i) = NULL;

      j = i + TYPE_LOW_BOUND(var->type->main_type->fields->type);

      /* check if child exists, if not create */
      name = name_of_child (var, j);
      child = child_exists (var, name);
      if (child == NULL)
	child = create_child (var, j, name);

      *((*childlist) + i) = child;
    }

will work in varobj_list_children in a language independent way.

I'll wait to see what Daniel says though, before submitting another patch.

Nick



[-- Attachment #2: fortran watch window --]
[-- Type: image/png, Size: 7841 bytes --]

Re: PATCH: Start Fortran support for variable objects.

[Wu Zhou]

> So I should have done:
> 
> (top-gdb) p TYPE_LOW_BOUND(var->type->main_type->fields->type)
> $1 = 1
> (top-gdb) p TYPE_HIGH_BOUND(var->type->main_type->fields->type)
> $2 = 4

Yes.  TYPE_LOW_BOUND is against the range_type.  So my guess is wrong 
indeed.  

Cheers
- Wu Zhou

Re: PATCH: Start Fortran support for variable objects.

[Daniel Jacobowitz]

On Fri, Jul 01, 2005 at 04:32:54PM +1200, Nick Roberts wrote:
> So I should have done:
> 
> (top-gdb) p TYPE_LOW_BOUND(var->type->main_type->fields->type)
> $1 = 1
> (top-gdb) p TYPE_HIGH_BOUND(var->type->main_type->fields->type)
> $2 = 4

Right - specifically, TYPE_LOW_BOUND (TYPE_INDEX_TYPE (var->type))
is supposed to be the lower bound for an array.  Tricky.  It comes from
read_subrange_type in dwarf2read.c for dwarf2.

>  > I guess there might be some errors in the process of creating varobj for 
>  > Fortran array.  
> 
> No the information seems to be there.  So maybe:
> 
>   for (i = 0; i < var->num_children; i++)
>     {
>       /* Mark as the end in case we bail out */
>       *((*childlist) + i) = NULL;
> 
>       j = i + TYPE_LOW_BOUND(var->type->main_type->fields->type);
> 
>       /* check if child exists, if not create */
>       name = name_of_child (var, j);
>       child = child_exists (var, name);
>       if (child == NULL)
> 	child = create_child (var, j, name);
> 
>       *((*childlist) + i) = child;
>     }
> 
> will work in varobj_list_children in a language independent way.
> 
> I'll wait to see what Daniel says though, before submitting another patch.

First of all, never reference ->main_type - see above for the right way
to get the low bound.  An even better way (it seems) is to call
get_discrete_bounds.  Take a look at value_subscript for an example.

I can't tell what f77_get_dynamic_lowerbound is supposed to handle.
But it does a really, really good impression of reading data which is
no longer set anywhere, so I have the feeling that it is dead code.
Sorry for pointing you at it.

So let's use TYPE_LOW_BOUND for now; does that eliminate the need for
the fortran-specific code?

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: PATCH: Start Fortran support for variable objects.

[Nick Roberts]

Daniel Jacobowitz writes:
 > On Fri, Jul 01, 2005 at 04:32:54PM +1200, Nick Roberts wrote:
 > > So I should have done:
 > > 
 > > (top-gdb) p TYPE_LOW_BOUND(var->type->main_type->fields->type)
 > > $1 = 1
 > > (top-gdb) p TYPE_HIGH_BOUND(var->type->main_type->fields->type)
 > > $2 = 4
 > 
 > Right - specifically, TYPE_LOW_BOUND (TYPE_INDEX_TYPE (var->type))
 > is supposed to be the lower bound for an array.  Tricky.  It comes from
 > read_subrange_type in dwarf2read.c for dwarf2.

Or even TYPE_ARRAY_LOWER_BOUND_VALUE (var->type)?

Presumably these macros are more general than dwarf2.  I don't understand the
connection with read_subrange_type.

 ...
 > First of all, never reference ->main_type - see above for the right way
 > to get the low bound.  An even better way (it seems) is to call
 > get_discrete_bounds.  Take a look at value_subscript for an example.

Better than TYPE_LOW_BOUND?

 ...
 > So let's use TYPE_LOW_BOUND for now; does that eliminate the need for
 > the fortran-specific code?

OK.  And, in future, bear get_discrete_bounds in mind?

Nick

Re: PATCH: Start Fortran support for variable objects.

[Daniel Jacobowitz]

On Mon, Jul 04, 2005 at 11:41:17AM +1200, Nick Roberts wrote:
> Daniel Jacobowitz writes:
>  > On Fri, Jul 01, 2005 at 04:32:54PM +1200, Nick Roberts wrote:
>  > > So I should have done:
>  > > 
>  > > (top-gdb) p TYPE_LOW_BOUND(var->type->main_type->fields->type)
>  > > $1 = 1
>  > > (top-gdb) p TYPE_HIGH_BOUND(var->type->main_type->fields->type)
>  > > $2 = 4
>  > 
>  > Right - specifically, TYPE_LOW_BOUND (TYPE_INDEX_TYPE (var->type))
>  > is supposed to be the lower bound for an array.  Tricky.  It comes from
>  > read_subrange_type in dwarf2read.c for dwarf2.
> 
> Or even TYPE_ARRAY_LOWER_BOUND_VALUE (var->type)?

Let's stick to TYPE_LOW_BOUND (TYPE_INDEX_TYPE (var->type)) for now. 
That macro appears to be fortran-specific, and part of the dead bits.

> Presumably these macros are more general than dwarf2.  I don't understand the
> connection with read_subrange_type.

It was just an example - that's somewhere that sets it, and knows about
the Fortran numbering convention.

>  > First of all, never reference ->main_type - see above for the right way
>  > to get the low bound.  An even better way (it seems) is to call
>  > get_discrete_bounds.  Take a look at value_subscript for an example.
> 
> Better than TYPE_LOW_BOUND?

I suppose.  I don't know which one is preferred; some day, someone
should go through and clean them all up to be consistent.  I'm fine
with either choice.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: PATCH: Start Fortran support for variable objects.

[Nick Roberts]

 > >  > First of all, never reference ->main_type - see above for the right way
 > >  > to get the low bound.  An even better way (it seems) is to call
 > >  > get_discrete_bounds.  Take a look at value_subscript for an example.
 > > 
 > > Better than TYPE_LOW_BOUND?
 > 
 > I suppose.  I don't know which one is preferred; some day, someone
 > should go through and clean them all up to be consistent.  I'm fine
 > with either choice.

To keep things simple I've used TYPE_LOW_BOUND.  I've tested with the examples
I've posted before and it works.  Presumably there should also be a test case,
so I'll create one for mi-var-child.exp and mi2-var-child.exp (you still
haven't approved my patch for mi2-cmd-stack.exp (28 Jun 2005 01:53:52 +1200).

In particular, this patch does eliminate the need for the fortran-specific
code.

Nick


2005-06-30  Nick Roberts  <nickrob@snap.net.nz>

	* varobj.c (varobj_list_children): Allow non-zero offsets for
	languages like Fortran.


Index: varobj.c
===================================================================
RCS file: /cvs/src/src/gdb/varobj.c,v
retrieving revision 1.54
diff -u -p -r1.54 varobj.c
--- varobj.c	26 Apr 2005 05:03:37 -0000	1.54
+++ varobj.c	4 Jul 2005 01:36:54 -0000
@@ -696,7 +696,7 @@ varobj_list_children (struct varobj *var
 {
   struct varobj *child;
   char *name;
-  int i;
+  int i, j, retcode;
 
   /* sanity check: have we been passed a pointer? */
   if (childlist == NULL)
@@ -715,11 +715,13 @@ varobj_list_children (struct varobj *var
       /* Mark as the end in case we bail out */
       *((*childlist) + i) = NULL;
 
+      j = i + TYPE_LOW_BOUND (TYPE_INDEX_TYPE (var->type));
+
       /* check if child exists, if not create */
-      name = name_of_child (var, i);
+      name = name_of_child (var, j);
       child = child_exists (var, name);
       if (child == NULL)
-	child = create_child (var, i, name);
+	child = create_child (var, j, name);
 
       *((*childlist) + i) = child;
     }

Re: PATCH: Start Fortran support for variable objects.

[Daniel Jacobowitz]

On Mon, Jul 04, 2005 at 01:41:13PM +1200, Nick Roberts wrote:
>  > >  > First of all, never reference ->main_type - see above for the right way
>  > >  > to get the low bound.  An even better way (it seems) is to call
>  > >  > get_discrete_bounds.  Take a look at value_subscript for an example.
>  > > 
>  > > Better than TYPE_LOW_BOUND?
>  > 
>  > I suppose.  I don't know which one is preferred; some day, someone
>  > should go through and clean them all up to be consistent.  I'm fine
>  > with either choice.
> 
> To keep things simple I've used TYPE_LOW_BOUND.  I've tested with the examples
> I've posted before and it works.  Presumably there should also be a test case,
> so I'll create one for mi-var-child.exp and mi2-var-child.exp (you still
> haven't approved my patch for mi2-cmd-stack.exp (28 Jun 2005 01:53:52 +1200).

You posted nothing to gdb-patches on June 27th, 28th, or 29th (except
for the first version of this patch).  I vaguely remember seeing a
patch on gdb@ when Mark complained about your introducing regressions.
But if you'd like it approved, please post it to the patches list; I am
methodical about processing gdb-patches mail because it has a clearly
defined request-reply format, and gdb@ discussions tend to wander off
on tangents (like that one did).

BTW, found the patch in the archives - the changelog entry is for the
wrong file.  Also, can we just remove the failing test, instead of
adding new tests to mi2?  We really need to get a coherent story
together on what "is" mi2, but I don't think we need to add tests for
new commands to it.

> 2005-06-30  Nick Roberts  <nickrob@snap.net.nz>
> 
> 	* varobj.c (varobj_list_children): Allow non-zero offsets for
> 	languages like Fortran.

Retcode is unused.

Can't we get here with struct types?  In which case this will blow up:

> +      j = i + TYPE_LOW_BOUND (TYPE_INDEX_TYPE (var->type));
> +
>        /* check if child exists, if not create */
> -      name = name_of_child (var, i);
> +      name = name_of_child (var, j);
>        child = child_exists (var, name);
>        if (child == NULL)
> -	child = create_child (var, i, name);
> +	child = create_child (var, j, name);
>  
>        *((*childlist) + i) = child;
>      }

Also, I'm beginning to wonder if you're doing this in the right place. 
Not that it matters a whole lot, but index is 0-based in every other
case, including for structs.  Maybe the children of arr(4) should be
arr.0 == arr(1), arr.1 == arr(2), arr.2 == arr(3), arr.3 == arr(4). 
Then you'd add the lower bound in c_value_of_child.  Does that work?
Do you have an opinion on which is "more right"?

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: PATCH: Start Fortran support for variable objects.

[Nick Roberts]

 > >                         ...(you still haven't approved my patch for
 > > mi2-cmd-stack.exp (28 Jun 2005 01:53:52 +1200).
 > 
 > You posted nothing to gdb-patches on June 27th, 28th, or 29th (except
 > for the first version of this patch).  I vaguely remember seeing a
 > patch on gdb@ when Mark complained about your introducing regressions.
 > But if you'd like it approved, please post it to the patches list; I am
 > methodical about processing gdb-patches mail because it has a clearly
 > defined request-reply format, and gdb@ discussions tend to wander off
 > on tangents (like that one did).

OK, I'll remember that in future.

 > BTW, found the patch in the archives - the changelog entry is for the
 > wrong file.  Also, can we just remove the failing test, instead of
 > adding new tests to mi2?  We really need to get a coherent story
 > together on what "is" mi2, but I don't think we need to add tests for
 > new commands to it.

It comes back to what I said earlier: In reality GDB doesn't support more than
one version of MI (the current one).  Even the recently implemented MI command
-stack-info-frame will work with -i=mi1.  There are small differences in
output format e.g the preamble that GDB prints out is put on the log stream
for mi2 but not mi1, but thats about it.  I would favour just supporting one
level with tests mi-*.exp.  That seems to be hard enough.  Apple seem to be
the only ones who are already using MI, and they have their own version
anyway.

 > 
 > > 2005-06-30  Nick Roberts  <nickrob@snap.net.nz>
 > > 
 > > 	* varobj.c (varobj_list_children): Allow non-zero offsets for
 > > 	languages like Fortran.
 > 
 > Retcode is unused.

OK.

 > Can't we get here with struct types?  In which case this will blow up:

Would this work?

  struct type *type;

      ...
      type = get_type (var);
      if (TYPE_CODE (type) == TYPE_CODE_ARRAY)
	j = i + TYPE_LOW_BOUND (TYPE_INDEX_TYPE (var->type));
      else
	j = i;

 > > +      j = i + TYPE_LOW_BOUND (TYPE_INDEX_TYPE (var->type));
 > > +
 > >        /* check if child exists, if not create */
 > > -      name = name_of_child (var, i);
 > > +      name = name_of_child (var, j);
 > >        child = child_exists (var, name);
 > >        if (child == NULL)
 > > -	child = create_child (var, i, name);
 > > +	child = create_child (var, j, name);
 > >  
 > >        *((*childlist) + i) = child;
 > >      }
 > 
 > Also, I'm beginning to wonder if you're doing this in the right place. 
 > Not that it matters a whole lot, but index is 0-based in every other
 > case, including for structs.  Maybe the children of arr(4) should be
 > arr.0 == arr(1), arr.1 == arr(2), arr.2 == arr(3), arr.3 == arr(4). 
 > Then you'd add the lower bound in c_value_of_child.  Does that work?
 > Do you have an opinion on which is "more right"?

I'll think this over (and the change above) and then submit another patch.

Nick

Re: PATCH: Start Fortran support for variable objects.

[Nick Roberts]

 > Also, I'm beginning to wonder if you're doing this in the right place. 
 > Not that it matters a whole lot, but index is 0-based in every other
 > case, including for structs.  Maybe the children of arr(4) should be
 > arr.0 == arr(1), arr.1 == arr(2), arr.2 == arr(3), arr.3 == arr(4). 
 > Then you'd add the lower bound in c_value_of_child.  Does that work?
 > Do you have an opinion on which is "more right"?

Unfortunately the index for "name" is used to compute the expression "exp"
(which makes it a bit redundant):

      INTEGER ARRAY2(-1:4)

Zero based gives:

(gdb) 
-var-list-children var1
^done,numchild="6",children=[child={name="var1.0",exp="0",numchild="0",type="integer"},child={name="var1.1",exp="1",numchild="0",type="integer"}...

My patch currently gives:

(gdb) 
-var-list-children var1
^done,numchild="6",children=[child={name="var1.-1",exp="-1",numchild="0",type="integer"},child={name="var1.0",exp="0",numchild="0",type="integer"}...

As (I think) you say, ideal would be:

(gdb) 
-var-list-children var1
^done,numchild="6",children=[child={name="var1.0",exp="-1",numchild="0",type="integer"},child={name="var1.1",exp="0",numchild="0",type="integer"}...


In any case it would make sense to compute the offset outside the loop as
shown below.

Nick


  type = get_type (var);
  if (TYPE_CODE (type) == TYPE_CODE_ARRAY)
    j = TYPE_LOW_BOUND (TYPE_INDEX_TYPE (var->type));
  else
    j = 0;

  for (i = 0; i < var->num_children; i++)
    {
      /* Mark as the end in case we bail out */
      *((*childlist) + i) = NULL;


      /* check if child exists, if not create */
      name = name_of_child (var, i + j);
      child = child_exists (var, name);
      if (child == NULL)
	  child = create_child (var, i + j, name);

      *((*childlist) + i) = child;
    }

Re: PATCH: Start Fortran support for variable objects.

[Wu Zhou]

On Sun, 3 Jul 2005, Daniel Jacobowitz wrote:

> On Fri, Jul 01, 2005 at 04:32:54PM +1200, Nick Roberts wrote:
> > So I should have done:
> > 
> > (top-gdb) p TYPE_LOW_BOUND(var->type->main_type->fields->type)
> > $1 = 1
> > (top-gdb) p TYPE_HIGH_BOUND(var->type->main_type->fields->type)
> > $2 = 4
> 
> Right - specifically, TYPE_LOW_BOUND (TYPE_INDEX_TYPE (var->type))
> is supposed to be the lower bound for an array.  Tricky.  It comes from
> read_subrange_type in dwarf2read.c for dwarf2.

Yes, it is tricky to me too.  Maybe it is better to change TYPE_INDEX_TYPE 
to TYPE_RANGE_TYPE.  This seems more obvious IMO.
 
- Wu Zhou

Re: PATCH: Start Fortran support for variable objects.

[Nick Roberts]

 > Also, I'm beginning to wonder if you're doing this in the right place. 
 > Not that it matters a whole lot, but index is 0-based in every other
 > case, including for structs.  Maybe the children of arr(4) should be
 > arr.0 == arr(1), arr.1 == arr(2), arr.2 == arr(3), arr.3 == arr(4). 
 > Then you'd add the lower bound in c_value_of_child.  Does that work?
 > Do you have an opinion on which is "more right"?

Here's a new patch which does the same as my last one.  So the children map as
before i.e arr.1 == arr(1) because the index for expression "exp" is used to
compute the "name".  However this time I've made changes to c_name_of_child
and c_value_of_child instead of varobj_list_children, so hopefully you'll find
it more agreeable.

If I don't change c_name_of_child, I get variable object names like arr.0 as
you suggest. However, then I also get exp="0" which I use for the index of the
watch expression.  I think this is confusing.


-- 
Nick                                           http://www.inet.net.nz/~nickrob


2006-03-13  Nick Roberts  <nickrob@snap.net.nz>

	* varobj.c (c_name_of_child, c_value_of_child): Allow non-zero
	offsets for languages like Fortran.


*** varobj.c	13 Mar 2006 17:21:09 +1300	1.58
--- varobj.c	13 Mar 2006 16:31:26 +1300	
*************** c_name_of_child (struct varobj *parent, 
*** 1833,1839 ****
    switch (TYPE_CODE (type))
      {
      case TYPE_CODE_ARRAY:
!       name = xstrprintf ("%d", index);
        break;
  
      case TYPE_CODE_STRUCT:
--- 1833,1839 ----
    switch (TYPE_CODE (type))
      {
      case TYPE_CODE_ARRAY:
!       name = xstrprintf ("%d", index + TYPE_LOW_BOUND (TYPE_INDEX_TYPE (type)));
        break;
  
      case TYPE_CODE_STRUCT:
*************** c_value_of_child (struct varobj *parent,
*** 1931,1936 ****
--- 1931,1937 ----
    struct value *indval;
    struct type *type, *target;
    char *name;
+   int real_index;
  
    type = get_type (parent);
    target = get_target_type (type);
*************** c_value_of_child (struct varobj *parent,
*** 1943,1955 ****
        switch (TYPE_CODE (type))
  	{
  	case TYPE_CODE_ARRAY:
  #if 0
  	  /* This breaks if the array lives in a (vector) register. */
! 	  value = value_slice (temp, index, 1);
  	  temp = value_coerce_array (value);
  	  gdb_value_ind (temp, &value);
  #else
! 	  indval = value_from_longest (builtin_type_int, (LONGEST) index);
  	  gdb_value_subscript (temp, indval, &value);
  #endif
  	  break;
--- 1944,1957 ----
        switch (TYPE_CODE (type))
  	{
  	case TYPE_CODE_ARRAY:
+ 	  real_index = index + TYPE_LOW_BOUND (TYPE_INDEX_TYPE (type));
  #if 0
  	  /* This breaks if the array lives in a (vector) register. */
! 	  value = value_slice (temp, real_index, 1);
  	  temp = value_coerce_array (value);
  	  gdb_value_ind (temp, &value);
  #else
! 	  indval = value_from_longest (builtin_type_int, (LONGEST) real_index);
  	  gdb_value_subscript (temp, indval, &value);
  #endif
  	  break;

Re: PATCH: Start Fortran support for variable objects.

[Daniel Jacobowitz]

On Mon, Mar 13, 2006 at 05:58:22PM +1300, Nick Roberts wrote:
> Here's a new patch which does the same as my last one.  So the children map as
> before i.e arr.1 == arr(1) because the index for expression "exp" is used to
> compute the "name".  However this time I've made changes to c_name_of_child
> and c_value_of_child instead of varobj_list_children, so hopefully you'll find
> it more agreeable.
> 
> If I don't change c_name_of_child, I get variable object names like arr.0 as
> you suggest. However, then I also get exp="0" which I use for the index of the
> watch expression.  I think this is confusing.

Yeah.  If I understand correctly, this patch will name the first
element of the array as var.-1 - is that right?

I think that's OK.  However, please add a gdb.mi testcase, and use
temporary variables or wrapping where necessary to avoid the overlong
lines; you added two.  If the testcase is a problem let me know and
I'll take care of it.

Thanks for seeing this through!

-- 
Daniel Jacobowitz
CodeSourcery

Re: PATCH: Start Fortran support for variable objects.

[Nick Roberts]

 > > If I don't change c_name_of_child, I get variable object names like arr.0
 > > as you suggest. However, then I also get exp="0" which I use for the
 > > index of the watch expression.  I think this is confusing.
 > 
 > Yeah.  If I understand correctly, this patch will name the first
 > element of the array as var.-1 - is that right?

Yes.

 > I think that's OK.  However, please add a gdb.mi testcase, and use
 > temporary variables or wrapping where necessary to avoid the overlong
 > lines; you added two.

How long is overlong?  The longest two lines are 79 and 78 characters (heck, I
could even fit them on a punched card!).  I think their appearance gets
slightly screwed up in the patch because they have tabs in them.

 >                         If the testcase is a problem let me know and
 > I'll take care of it.

I've had a go (patch attached).  Running the testsuite in gdb.mi I get:

# of expected passes		1236
# of unexpected failures	7
# of expected failures		28
# of known failures		1
/home/nickrob/src/gdb/testsuite/../../gdb/gdb version  6.4.50.20060325-cvs -nx

FAIL: gdb.mi/mi-file.exp: Getting a list of source files.
FAIL: gdb.mi/mi-basics.exp: environment-directory arg operation
FAIL: gdb.mi/mi-basics.exp: environment-directory empty-string operation
FAIL: gdb.mi/mi-basics.exp: environment-path dir1 dir2 operation
FAIL: gdb.mi/mi2-basics.exp: environment-directory arg operation
FAIL: gdb.mi/mi2-basics.exp: environment-directory empty-string operation
FAIL: gdb.mi/mi2-basics.exp: environment-path dir1 dir2 operation


I'm pretty sure the fails have always been there for me.

-- 
Nick                                           http://www.inet.net.nz/~nickrob


2006-03-26  Nick Roberts  <nickrob@snap.net.nz>

	* gdb.mi/mi-var-child-f.exp, gdb.mi/array.f: New files.


c Copyright 2006 Free Software Foundation, Inc.

c This program is free software; you can redistribute it and/or modify
c it under the terms of the GNU General Public License as published by
c the Free Software Foundation; either version 2 of the License, or
c (at your option) any later version.
c 
c This program is distributed in the hope that it will be useful,
c but WITHOUT ANY WARRANTY; without even the implied warranty of
c MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
c GNU General Public License for more details.
c 
c You should have received a copy of the GNU General Public License
c along with GNU Emacs; see the file COPYING.  If not, write to the
c Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
c Boston, MA 02110-1301, USA.

      INTEGER array(1:2,-1:1)
      DATA array/11,21,12,22,13,23/
      CONTINUE
      STOP
      END


# Copyright 2006 Free Software Foundation, Inc.

# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
# 
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
# 
# You should have received a copy of the GNU General Public License
# along with GNU Emacs; see the file COPYING.  If not, write to the
# Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
# Boston, MA 02110-1301, USA.

# Test variable objects treat non-zero offsets in Fortran arrays correbtly.

load_lib mi-support.exp
set MIFLAGS "-i=mi"

gdb_exit
if [mi_gdb_start] {
    continue
}

set testfile "array"
set srcfile ${testfile}.f
set binfile ${objdir}/${subdir}/${testfile}
if  { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug f77 quiet}] != "" } {
    untested "Couldn't compile ${srcfile}"
    return -1
}

mi_gdb_reinitialize_dir $srcdir/$subdir
mi_gdb_load ${binfile}

mi_runto MAIN__

mi_gdb_test "-var-create array * array" \
    "\\^done,name=\"array\",numchild=\"3\",type=\"integer \\(2,-1:1\\)\"" \
    "create local variable array"

mi_gdb_test "-var-list-children --all-values array" \
    "\\^done,numchild=\"3\",children=\\\[child=\{name=\"array.-1\",exp=\"-1\",numchild=\"2\",value=\"\\\[2\\\]\",type=\"integer \\(2\\)\"\},child=\{name=\"array.0\",exp=\"0\",numchild=\"2\",value=\"\\\[2\\\]\",type=\"integer \\(2\\)\"\},child=\{name=\"array.1\",exp=\"1\",numchild=\"2\",value=\"\\\[2\\\]\",type=\"integer \\(2\\)\"\}\\\]" \
    "get children of array"

mi_gdb_test "-var-list-children --all-values array.-1" \
    "\\^done,numchild=\"2\",children=\\\[child=\{name=\"array.-1.1\",exp=\"1\",numchild=\"0\",value=\"11\",type=\"integer\"\},child=\{name=\"array.-1.2\",exp=\"2\",numchild=\"0\",value=\"21\",type=\"integer\"\}\\\]" \
    "get grandchildren of array (children of first element of second index)"

Re: PATCH: Start Fortran support for variable objects.

[Daniel Jacobowitz]

On Sun, Mar 26, 2006 at 10:14:29PM +1200, Nick Roberts wrote:
> How long is overlong?  The longest two lines are 79 and 78 characters (heck, I
> could even fit them on a punched card!).  I think their appearance gets
> slightly screwed up in the patch because they have tabs in them.

Hmm - confusion on my part - but on yours too it seems?

My rule for "too long" is "open emacs in an eighty-column terminal, and
if it wraps them, they're too long".  The one in c_value_of_child just
fits, but the one in c_name_of_child has one too many - emacs
starts at column 0, not column 1, so a semicolon in column 79 means
that emacs will push the semicolon onto the next line (to have room for
the continuation backslash and a space after the cursor).

> FAIL: gdb.mi/mi-file.exp: Getting a list of source files.
> FAIL: gdb.mi/mi-basics.exp: environment-directory arg operation
> FAIL: gdb.mi/mi-basics.exp: environment-directory empty-string operation
> FAIL: gdb.mi/mi-basics.exp: environment-path dir1 dir2 operation
> FAIL: gdb.mi/mi2-basics.exp: environment-directory arg operation
> FAIL: gdb.mi/mi2-basics.exp: environment-directory empty-string operation
> FAIL: gdb.mi/mi2-basics.exp: environment-path dir1 dir2 operation
> 
> 
> I'm pretty sure the fails have always been there for me.

IIRC the mi-basics failures come from configuring GDB using a relative
path.  I don't know the mi-file.exp failure offhand.  But, anyway, this
is plenty good.

It's not hard to do this twice, though, so that you know you have no
new failures - once with the patch and once without.

> 2006-03-26  Nick Roberts  <nickrob@snap.net.nz>
> 
> 	* gdb.mi/mi-var-child-f.exp, gdb.mi/array.f: New files.

Patch is OK with one line wrapped, testcase is OK, thanks a lot!

-- 
Daniel Jacobowitz
CodeSourcery

Re: PATCH: Start Fortran support for variable objects.

[Nick Roberts]

 > My rule for "too long" is "open emacs in an eighty-column terminal, and
 > if it wraps them, they're too long".  The one in c_value_of_child just
 > fits, but the one in c_name_of_child has one too many - emacs
 > starts at column 0, not column 1, 

You're right the lines were 79 and 80 cols wide.

 >                                        so a semicolon in column 79 means
 > that emacs will push the semicolon onto the next line (to have room for
 > the continuation backslash and a space after the cursor).

Not on Emacs 22: the cursor gets pushed into the fringe - anyway I've wrapped
the line, not wishing to appear a sore loser.

 > > FAIL: gdb.mi/mi-file.exp: Getting a list of source files.
 > > FAIL: gdb.mi/mi-basics.exp: environment-directory arg operation
 > > FAIL: gdb.mi/mi-basics.exp: environment-directory empty-string operation
 > > FAIL: gdb.mi/mi-basics.exp: environment-path dir1 dir2 operation
 > > FAIL: gdb.mi/mi2-basics.exp: environment-directory arg operation
 > > FAIL: gdb.mi/mi2-basics.exp: environment-directory empty-string operation
 > > FAIL: gdb.mi/mi2-basics.exp: environment-path dir1 dir2 operation
 > > 
 > > 
 > > I'm pretty sure the fails have always been there for me.
 > 
 > IIRC the mi-basics failures come from configuring GDB using a relative
 > path.  I don't know the mi-file.exp failure offhand.  But, anyway, this
 > is plenty good.
 > 
 > It's not hard to do this twice, though, so that you know you have no
 > new failures - once with the patch and once without.

OK, I'll remember that.

 > > 2006-03-26  Nick Roberts  <nickrob@snap.net.nz>
 > > 
 > > 	* gdb.mi/mi-var-child-f.exp, gdb.mi/array.f: New files.
 > 
 > Patch is OK with one line wrapped, testcase is OK, thanks a lot!

Comitted.

Nick                                           http://www.inet.net.nz/~nickrob

Re: PATCH: Start Fortran support for variable objects.

[Daniel Jacobowitz]

On Mon, Mar 27, 2006 at 12:33:34PM +1200, Nick Roberts wrote:
>  >                                        so a semicolon in column 79 means
>  > that emacs will push the semicolon onto the next line (to have room for
>  > the continuation backslash and a space after the cursor).
> 
> Not on Emacs 22: the cursor gets pushed into the fringe - anyway I've wrapped
> the line, not wishing to appear a sore loser.

Oh, nice!  Anyway, thanks a lot.

-- 
Daniel Jacobowitz
CodeSourcery