* [RFC]: Document patch for F90 derived type support
@ 2006-02-24 8:13 Wu Zhou
2006-02-24 8:34 ` Eli Zaretskii
0 siblings, 1 reply; 23+ messages in thread
From: Wu Zhou @ 2006-02-24 8:13 UTC (permalink / raw)
To: gdb-patches
Eli,
Here is the modified document patch for F90 derived type support. Please
review and comment.
I had tested it with "make info". It displays ok.
2006-02-24 Wu Zhou <woodzltc@cn.ibm.com>
* gdb.texinfo (Fortran): Document the "%" operator for member
access. Document the type-print and value-print operation of
Fortran 90 derived types.
Index: gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.314
diff -c -p -r1.314 gdb.texinfo
*** gdb.texinfo 18 Feb 2006 20:45:01 -0000 1.314
--- gdb.texinfo 24 Feb 2006 07:16:56 -0000
*************** of the second one.
*** 9399,9404 ****
--- 9399,9408 ----
@item :
The range operator. Normally used in the form of array(low:high) to
represent a section of array.
+
+ @item %
+ Fortran 90 and later use this to access the members of derived
+ type, which is also introduced after the Fortran 90.
@end table
@node Fortran Defaults
*************** This command prints the values contained
*** 9427,9432 ****
--- 9431,9506 ----
block whose name is @var{common-name}. With no argument, the names of
all @code{COMMON} blocks visible at current program location are
printed.
+
+ @cindex structure type-print
+ @item ptype @var{derived-type}
+ Fortran 90 and later support derived type (a.k.a structure). For a
+ variable of derived type, the @code{ptype} command will output all its
+ members, including nested derived type.
+
+ For example, for this derived type declaration:
+
+ @smallexample
+ type bar
+ integer :: c
+ real :: d
+ end type
+
+ type foo
+ real :: a
+ type(bar) :: x
+ character*7 :: b
+ end type foo
+ @end smallexample
+
+ @noindent
+ the @code{ptype} commands give this output:
+
+ @smallexample
+ @group
+ (@value{GDBP}) ptype bar
+ type = Type bar
+ int4 :: c
+ real*4 :: d
+ End Type bar
+ (@value{GDBP}) ptype foo
+ type = Type foo
+ real*4 :: a
+ Type bar
+ int4 :: c
+ real*4 :: d
+ End Type bar :: x
+ character (7) :: b
+ End Type foo
+ @end group
+ @end smallexample
+
+ @cindex structure value-print
+ @item print @var{derived-type}
+ For a variable of derived type, the @code{print} command will output the
+ value of all its members, including its nested derived type .
+
+ For example, for variable q of type foo defined above:
+
+ @smallexample
+ type(foo) :: q
+ @end smallexample
+
+ @noindent
+ the @code{print} command will output this:
+
+ @smallexample
+ @group
+ (@value{GDBP}) print q
+ $1 = @{ 3.125, @{ 1, 2.375@},
+ (97 'a', 98 'b', 99 'c', 100 'd', 101 'e', 102 'f', 103 'g')@}
+ @end group
+ @end smallexample
+
+ Please be noted that in the above example, the result of @code{print q}
+ is a single long line, broken only for clarity.
+ @noindent
+
@end table
@node Pascal
Regards
- Wu Zhou
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [RFC]: Document patch for F90 derived type support
2006-02-24 8:13 [RFC]: Document patch for F90 derived type support Wu Zhou
@ 2006-02-24 8:34 ` Eli Zaretskii
2006-02-27 5:59 ` Wu Zhou
0 siblings, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2006-02-24 8:34 UTC (permalink / raw)
To: Wu Zhou; +Cc: gdb-patches
> Date: Fri, 24 Feb 2006 02:54:16 -0500 (EST)
> From: Wu Zhou <woodzltc@cn.ibm.com>
>
> Here is the modified document patch for F90 derived type support. Please
> review and comment.
Reviewed; comments below.
> + Fortran 90 and later support derived type (a.k.a structure). For a
^^^^^
This should be "a.k.a.@:". You forgot the last period, and @: tells
TeX that this period does not end a sentence, so that TeX typeset it
correctly.
> + type = Type bar
> + int4 :: c
> + real*4 :: d
> + End Type bar
Btw, isn't it more consistent to print "integer*4" instead of "int4"?
Either that, or just "integer", I think. Or is "int4" a valid type
name in f90? (The last Fortran I used was f77, so please forgive my
ignorance.)
> + For example, for variable q of type foo defined above:
"q" and "foo" should be in @code (they are program symbols).
> + Please be noted that in the above example, the result of @code{print q}
^^^^^^^^^^^^^^^
"Please note".
Other than that, fine with me. Thanks.
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [RFC]: Document patch for F90 derived type support
2006-02-24 8:34 ` Eli Zaretskii
@ 2006-02-27 5:59 ` Wu Zhou
2006-02-28 6:43 ` Eli Zaretskii
0 siblings, 1 reply; 23+ messages in thread
From: Wu Zhou @ 2006-02-27 5:59 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb-patches
Eli,
Thanks for your quick review! Please see my answers below.
On Fri, 24 Feb 2006, Eli Zaretskii wrote:
> > Date: Fri, 24 Feb 2006 02:54:16 -0500 (EST)
> > From: Wu Zhou <woodzltc@cn.ibm.com>
> >
> > Here is the modified document patch for F90 derived type support. Please
> > review and comment.
>
> Reviewed; comments below.
>
> > + Fortran 90 and later support derived type (a.k.a structure). For a
> ^^^^^
> This should be "a.k.a.@:". You forgot the last period, and @: tells
> TeX that this period does not end a sentence, so that TeX typeset it
> correctly.
Thanks for the correction. Modified.
> > + type = Type bar
> > + int4 :: c
> > + real*4 :: d
> > + End Type bar
>
> Btw, isn't it more consistent to print "integer*4" instead of "int4"?
> Either that, or just "integer", I think. Or is "int4" a valid type
> name in f90? (The last Fortran I used was f77, so please forgive my
> ignorance.)
Yes. I also think so. But the name of "int4" is got from the DWARF tag:
<1><e6>: Abbrev Number: 4 (DW_TAG_base_type)
DW_AT_name : int4
DW_AT_byte_size : 4
DW_AT_encoding : 5 (signed)
Maybe we can suggest the compiler to generate integer or integer*4
instead.
> > + For example, for variable q of type foo defined above:
>
> "q" and "foo" should be in @code (they are program symbols).
Modified.
>
> > + Please be noted that in the above example, the result of @code{print q}
> ^^^^^^^^^^^^^^^
> "Please note".
Thanks. The modified patch is appended below:
2006-02-27 Wu Zhou <woodzltc@cn.ibm.com>
* gdb.texinfo (Fortran): Document the "%" operator for member
access. Document the type-print and value-print operation of
Fortran 90 derived types.
Index: gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.314
diff -c -p -r1.314 gdb.texinfo
*** gdb.texinfo 18 Feb 2006 20:45:01 -0000 1.314
--- gdb.texinfo 27 Feb 2006 02:59:47 -0000
*************** of the second one.
*** 9399,9404 ****
--- 9399,9408 ----
@item :
The range operator. Normally used in the form of array(low:high) to
represent a section of array.
+
+ @item %
+ Fortran 90 and later use this to access the members of derived
+ type, which is also introduced after the Fortran 90.
@end table
@node Fortran Defaults
*************** This command prints the values contained
*** 9427,9432 ****
--- 9431,9506 ----
block whose name is @var{common-name}. With no argument, the names of
all @code{COMMON} blocks visible at current program location are
printed.
+
+ @cindex structure type-print
+ @item ptype @var{derived-type}
+ Fortran 90 and later support derived type (a.k.a.@: structure). For a
+ variable of derived type, the @code{ptype} command will output all its
+ members, including nested derived type.
+
+ For example, for this derived type declaration:
+
+ @smallexample
+ type bar
+ integer :: c
+ real :: d
+ end type
+
+ type foo
+ real :: a
+ type(bar) :: x
+ character*7 :: b
+ end type foo
+ @end smallexample
+
+ @noindent
+ the @code{ptype} commands give this output:
+
+ @smallexample
+ @group
+ (@value{GDBP}) ptype bar
+ type = Type bar
+ int4 :: c
+ real*4 :: d
+ End Type bar
+ (@value{GDBP}) ptype foo
+ type = Type foo
+ real*4 :: a
+ Type bar
+ int4 :: c
+ real*4 :: d
+ End Type bar :: x
+ character (7) :: b
+ End Type foo
+ @end group
+ @end smallexample
+
+ @cindex structure value-print
+ @item print @var{derived-type}
+ For a variable of derived type, the @code{print} command will output the
+ value of all its members, including its nested derived type .
+
+ For example, for variable @code{q} of type @code{foo} defined above:
+
+ @smallexample
+ type(foo) :: q
+ @end smallexample
+
+ @noindent
+ the @code{print} command will output this:
+
+ @smallexample
+ @group
+ (@value{GDBP}) print q
+ $1 = @{ 3.125, @{ 1, 2.375@},
+ (97 'a', 98 'b', 99 'c', 100 'd', 101 'e', 102 'f', 103 'g')@}
+ @end group
+ @end smallexample
+
+ Please note that in the above example, the result of @code{print q} is
+ a single long line, broken only for clarity.
+ @noindent
+
@end table
@node Pascal
Regards
- Wu Zhou
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [RFC]: Document patch for F90 derived type support
2006-02-27 5:59 ` Wu Zhou
@ 2006-02-28 6:43 ` Eli Zaretskii
2006-02-28 15:05 ` Daniel Jacobowitz
0 siblings, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2006-02-28 6:43 UTC (permalink / raw)
To: Wu Zhou; +Cc: gdb-patches
> Date: Sun, 26 Feb 2006 23:34:40 -0500 (EST)
> From: Wu Zhou <woodzltc@cn.ibm.com>
> cc: gdb-patches@sources.redhat.com
>
> > > + type = Type bar
> > > + int4 :: c
> > > + real*4 :: d
> > > + End Type bar
> >
> > Btw, isn't it more consistent to print "integer*4" instead of "int4"?
> > Either that, or just "integer", I think. Or is "int4" a valid type
> > name in f90? (The last Fortran I used was f77, so please forgive my
> > ignorance.)
>
> Yes. I also think so. But the name of "int4" is got from the DWARF tag:
>
> <1><e6>: Abbrev Number: 4 (DW_TAG_base_type)
> DW_AT_name : int4
> DW_AT_byte_size : 4
> DW_AT_encoding : 5 (signed)
Well, we don't need t print everything DWARF-2 throws at us verbatim.
If you agree with my suggestions, I say let's use them. Are there any
problems with that?
> + For a variable of derived type, the @code{print} command will output the
> + value of all its members, including its nested derived type .
^^
An extra space.
> + Please note that in the above example, the result of @code{print q} is
@kbd{print q}, since it's what the user types at her keyboard.
Otherwise okay, thanks.
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [RFC]: Document patch for F90 derived type support
2006-02-28 6:43 ` Eli Zaretskii
@ 2006-02-28 15:05 ` Daniel Jacobowitz
2006-02-28 20:09 ` Eli Zaretskii
0 siblings, 1 reply; 23+ messages in thread
From: Daniel Jacobowitz @ 2006-02-28 15:05 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Wu Zhou, gdb-patches
On Tue, Feb 28, 2006 at 07:37:46AM +0200, Eli Zaretskii wrote:
> > Date: Sun, 26 Feb 2006 23:34:40 -0500 (EST)
> > From: Wu Zhou <woodzltc@cn.ibm.com>
> > cc: gdb-patches@sources.redhat.com
> >
> > > > + type = Type bar
> > > > + int4 :: c
> > > > + real*4 :: d
> > > > + End Type bar
> > >
> > > Btw, isn't it more consistent to print "integer*4" instead of "int4"?
> > > Either that, or just "integer", I think. Or is "int4" a valid type
> > > name in f90? (The last Fortran I used was f77, so please forgive my
> > > ignorance.)
> >
> > Yes. I also think so. But the name of "int4" is got from the DWARF tag:
> >
> > <1><e6>: Abbrev Number: 4 (DW_TAG_base_type)
> > DW_AT_name : int4
> > DW_AT_byte_size : 4
> > DW_AT_encoding : 5 (signed)
>
> Well, we don't need t print everything DWARF-2 throws at us verbatim.
> If you agree with my suggestions, I say let's use them. Are there any
> problems with that?
Normally we try to honor the type names in debug info. If int4 is a
bogus name for a type in Fortran, then this debug info is bogus -
gfortran should be fixed.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC]: Document patch for F90 derived type support
2006-02-28 15:05 ` Daniel Jacobowitz
@ 2006-02-28 20:09 ` Eli Zaretskii
2006-03-01 2:51 ` Wu Zhou
0 siblings, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2006-02-28 20:09 UTC (permalink / raw)
To: Wu Zhou, gdb-patches
> Date: Tue, 28 Feb 2006 08:53:10 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Wu Zhou <woodzltc@cn.ibm.com>, gdb-patches@sources.redhat.com
>
> Normally we try to honor the type names in debug info.
If they make sense, sure. If they don't, I don't think we should
blindly follow them.
> If int4 is a bogus name for a type in Fortran, then this debug info
> is bogus - gfortran should be fixed.
I agree, but at least one version of gfortran that uses int4 is
already out there, so I suggest that GDB handles that as we think it's
right.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC]: Document patch for F90 derived type support
2006-02-28 20:09 ` Eli Zaretskii
@ 2006-03-01 2:51 ` Wu Zhou
2006-03-01 4:32 ` Daniel Jacobowitz
2006-03-01 4:51 ` Eli Zaretskii
0 siblings, 2 replies; 23+ messages in thread
From: Wu Zhou @ 2006-03-01 2:51 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb-patches
On Tue, 28 Feb 2006, Eli Zaretskii wrote:
> > Date: Tue, 28 Feb 2006 08:53:10 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: Wu Zhou <woodzltc@cn.ibm.com>, gdb-patches@sources.redhat.com
> >
> > Normally we try to honor the type names in debug info.
>
> If they make sense, sure. If they don't, I don't think we should
> blindly follow them.
I did some comparison between g77 and gfortran. In the aspect of the
compiler-generated DW_TAG_base_type, g77 uses "byte", "word" and "integer"
for "integer*1", "integer*2" and "integer*4" respectively. And gfortran
seems to adopt a new mechanism, it uses "int1", "int2" and "int4"
respectively. So it might also make some sense. At lease the debugger
user can guess the meaning from these words. :-)
> > If int4 is a bogus name for a type in Fortran, then this debug info
> > is bogus - gfortran should be fixed.
>
> I agree, but at least one version of gfortran that uses int4 is
> already out there, so I suggest that GDB handles that as we think it's
> right.
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC]: Document patch for F90 derived type support
2006-03-01 2:51 ` Wu Zhou
@ 2006-03-01 4:32 ` Daniel Jacobowitz
2006-03-01 4:53 ` Eli Zaretskii
2006-03-01 4:51 ` Eli Zaretskii
1 sibling, 1 reply; 23+ messages in thread
From: Daniel Jacobowitz @ 2006-03-01 4:32 UTC (permalink / raw)
To: Wu Zhou; +Cc: Eli Zaretskii, gdb-patches
On Tue, Feb 28, 2006 at 09:51:24PM -0500, Wu Zhou wrote:
>
> On Tue, 28 Feb 2006, Eli Zaretskii wrote:
>
> > > Date: Tue, 28 Feb 2006 08:53:10 -0500
> > > From: Daniel Jacobowitz <drow@false.org>
> > > Cc: Wu Zhou <woodzltc@cn.ibm.com>, gdb-patches@sources.redhat.com
> > >
> > > Normally we try to honor the type names in debug info.
> >
> > If they make sense, sure. If they don't, I don't think we should
> > blindly follow them.
>
> I did some comparison between g77 and gfortran. In the aspect of the
> compiler-generated DW_TAG_base_type, g77 uses "byte", "word" and "integer"
> for "integer*1", "integer*2" and "integer*4" respectively. And gfortran
> seems to adopt a new mechanism, it uses "int1", "int2" and "int4"
> respectively. So it might also make some sense. At lease the debugger
> user can guess the meaning from these words. :-)
I think they're close enough to display for now; I spoke with Paul
Brook and there shouldn't be any trouble changing them if we want to.
Eli, I agree that it would be reasonable to ignore them; but I don't
think there's any particularly easy way to do it.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC]: Document patch for F90 derived type support
2006-03-01 4:32 ` Daniel Jacobowitz
@ 2006-03-01 4:53 ` Eli Zaretskii
2006-03-01 5:05 ` Daniel Jacobowitz
0 siblings, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2006-03-01 4:53 UTC (permalink / raw)
To: Wu Zhou, gdb-patches
> Date: Tue, 28 Feb 2006 23:32:03 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, gdb-patches@sources.redhat.com
>
> > I did some comparison between g77 and gfortran. In the aspect of the
> > compiler-generated DW_TAG_base_type, g77 uses "byte", "word" and "integer"
> > for "integer*1", "integer*2" and "integer*4" respectively. And gfortran
> > seems to adopt a new mechanism, it uses "int1", "int2" and "int4"
> > respectively. So it might also make some sense. At lease the debugger
> > user can guess the meaning from these words. :-)
>
> I think they're close enough to display for now
``For now''? Are we in a hurry to release GDB or something?
> I spoke with Paul Brook and there shouldn't be any trouble changing
> them if we want to.
But what about the versions that are already there? We want GDB to
behave consistently, even of gfortran does not.
> Eli, I agree that it would be reasonable to ignore them; but I don't
> think there's any particularly easy way to do it.
??? Won't something as simple as
if (strcmp ("int4", ...) == 0)
printf_filtered ("integer*4");
do? What am I missing?
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [RFC]: Document patch for F90 derived type support
2006-03-01 4:53 ` Eli Zaretskii
@ 2006-03-01 5:05 ` Daniel Jacobowitz
2006-03-01 19:02 ` Eli Zaretskii
0 siblings, 1 reply; 23+ messages in thread
From: Daniel Jacobowitz @ 2006-03-01 5:05 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Wu Zhou, gdb-patches
On Wed, Mar 01, 2006 at 06:53:44AM +0200, Eli Zaretskii wrote:
> > > I did some comparison between g77 and gfortran. In the aspect of the
> > > compiler-generated DW_TAG_base_type, g77 uses "byte", "word" and "integer"
> > > for "integer*1", "integer*2" and "integer*4" respectively. And gfortran
> > > seems to adopt a new mechanism, it uses "int1", "int2" and "int4"
> > > respectively. So it might also make some sense. At lease the debugger
> > > user can guess the meaning from these words. :-)
> >
> > I think they're close enough to display for now
>
> ``For now''? Are we in a hurry to release GDB or something?
No, but my point was that there is no urgency in fixing it, which
allows us to fix gfortran instead.
> > I spoke with Paul Brook and there shouldn't be any trouble changing
> > them if we want to.
>
> But what about the versions that are already there? We want GDB to
> behave consistently, even of gfortran does not.
This is the same name that, e.g., gfortran probably uses in some
error messages. I believe there's value in being consistent with
the compiler that the user is actually using.
You can argue it either way, I don't disagree. I don't see either
side as particularly more compelling than the other. For C++
we've been leaning towards consistency within GDB, although
we mostly implement consistency with the user's compiler - and
in some cases there's no choice about it.
> > Eli, I agree that it would be reasonable to ignore them; but I don't
> > think there's any particularly easy way to do it.
>
> ??? Won't something as simple as
>
> if (strcmp ("int4", ...) == 0)
> printf_filtered ("integer*4");
>
> do? What am I missing?
No, it can't be quite that simple, because current versions of Fortran
do support user-named types - "int4" does not necessarily imply
integer(4). And future versions of the language may even have typedefs
for basic types.
Paul also corrected me on the naming - this would be integer(4)
apparently, integer*4 is something different.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [RFC]: Document patch for F90 derived type support
2006-03-01 5:05 ` Daniel Jacobowitz
@ 2006-03-01 19:02 ` Eli Zaretskii
2006-03-01 19:38 ` Daniel Jacobowitz
0 siblings, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2006-03-01 19:02 UTC (permalink / raw)
To: Wu Zhou, gdb-patches
> Date: Wed, 1 Mar 2006 00:05:01 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Wu Zhou <woodzltc@cn.ibm.com>, gdb-patches@sources.redhat.com
>
> This is the same name that, e.g., gfortran probably uses in some
> error messages.
If "int4" is the official gfortran name (is it?), then I agree we
should leave it alone.
> No, it can't be quite that simple, because current versions of Fortran
> do support user-named types - "int4" does not necessarily imply
> integer(4).
Perhaps I'm confused: isn't "int4" a 32-bit integer? I thought it
was, but if I was mistaken, my apologies for the noise.
> Paul also corrected me on the naming - this would be integer(4)
> apparently, integer*4 is something different.
Can you (or someone else) elaborate, or point me to some document that
does?
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC]: Document patch for F90 derived type support
2006-03-01 19:02 ` Eli Zaretskii
@ 2006-03-01 19:38 ` Daniel Jacobowitz
2006-03-02 2:32 ` Wu Zhou
2006-03-02 4:25 ` Eli Zaretskii
0 siblings, 2 replies; 23+ messages in thread
From: Daniel Jacobowitz @ 2006-03-01 19:38 UTC (permalink / raw)
To: gdb-patches
On Wed, Mar 01, 2006 at 09:02:34PM +0200, Eli Zaretskii wrote:
> > Date: Wed, 1 Mar 2006 00:05:01 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: Wu Zhou <woodzltc@cn.ibm.com>, gdb-patches@sources.redhat.com
> >
> > This is the same name that, e.g., gfortran probably uses in some
> > error messages.
>
> If "int4" is the official gfortran name (is it?), then I agree we
> should leave it alone.
I'm not sure if "official" is really strong enough; I suspect it will
use it in some user messages, as well as in debug information.
> > No, it can't be quite that simple, because current versions of Fortran
> > do support user-named types - "int4" does not necessarily imply
> > integer(4).
>
> Perhaps I'm confused: isn't "int4" a 32-bit integer? I thought it
> was, but if I was mistaken, my apologies for the noise.
It's not reserved at all in the input to the compiler - it might be
something different than a type, or it might be the name of a record
type (whatever the correct name for that is).
> > Paul also corrected me on the naming - this would be integer(4)
> > apparently, integer*4 is something different.
>
> Can you (or someone else) elaborate, or point me to some document that
> does?
I believe integer(4) is an integer with kind == 4. Paul wrote:
> integer(4) is the standard way, though the "4" has no particular meaning.
> integer*4 is a nonstandard (but common) extension saying "I want an
> integer 4 somthings wide". This may or may not be the same as integer(4).
Make of that whatever you want to...
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC]: Document patch for F90 derived type support
2006-03-01 19:38 ` Daniel Jacobowitz
@ 2006-03-02 2:32 ` Wu Zhou
2006-03-02 4:36 ` Eli Zaretskii
2006-03-02 4:25 ` Eli Zaretskii
1 sibling, 1 reply; 23+ messages in thread
From: Wu Zhou @ 2006-03-02 2:32 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb-patches
Maybe we can do this:
case TYPE_CODE_INT:
/* There may be some character types that attempt to come
through as TYPE_CODE_INT since dbxstclass.h is so
C-oriented, we must change these to "character" from "char". */
if (strcmp (TYPE_NAME (type), "char") == 0)
fprintfi_filtered (level, stream, "character");
else
fprintfi_filtered (level, stream, "integer (%d)", TYPE_LENGTH (type));
break;
The basic idea is to let the TYPE_CODE (type) and TYPE_LENGTH (type) to
determine what should be displayed.
This might be inconsistent with what the compiler generats (there is also
a benefit in this too, we don't need't adapt to all these different
compilers, which might generate different names for these types). But it
is acceptable by the programmer I believe. And also conform to the
language standard.
Any comment on this?
Regards
- Wu Zhou
On Wed, 1 Mar 2006, Daniel Jacobowitz wrote:
> On Wed, Mar 01, 2006 at 09:02:34PM +0200, Eli Zaretskii wrote:
> > > Date: Wed, 1 Mar 2006 00:05:01 -0500
> > > From: Daniel Jacobowitz <drow@false.org>
> > > Cc: Wu Zhou <woodzltc@cn.ibm.com>, gdb-patches@sources.redhat.com
> > >
> > > This is the same name that, e.g., gfortran probably uses in some
> > > error messages.
> >
> > If "int4" is the official gfortran name (is it?), then I agree we
> > should leave it alone.
>
> I'm not sure if "official" is really strong enough; I suspect it will
> use it in some user messages, as well as in debug information.
>
> > > No, it can't be quite that simple, because current versions of Fortran
> > > do support user-named types - "int4" does not necessarily imply
> > > integer(4).
> >
> > Perhaps I'm confused: isn't "int4" a 32-bit integer? I thought it
> > was, but if I was mistaken, my apologies for the noise.
>
> It's not reserved at all in the input to the compiler - it might be
> something different than a type, or it might be the name of a record
> type (whatever the correct name for that is).
>
> > > Paul also corrected me on the naming - this would be integer(4)
> > > apparently, integer*4 is something different.
> >
> > Can you (or someone else) elaborate, or point me to some document that
> > does?
>
> I believe integer(4) is an integer with kind == 4. Paul wrote:
>
> > integer(4) is the standard way, though the "4" has no particular meaning.
> > integer*4 is a nonstandard (but common) extension saying "I want an
> > integer 4 somthings wide". This may or may not be the same as integer(4).
>
> Make of that whatever you want to...
>
> --
> Daniel Jacobowitz
> CodeSourcery
>
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [RFC]: Document patch for F90 derived type support
2006-03-02 2:32 ` Wu Zhou
@ 2006-03-02 4:36 ` Eli Zaretskii
2006-03-02 4:40 ` Daniel Jacobowitz
0 siblings, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2006-03-02 4:36 UTC (permalink / raw)
To: Wu Zhou; +Cc: drow, gdb-patches
> Date: Wed, 1 Mar 2006 21:33:35 -0500 (EST)
> From: Wu Zhou <woodzltc@cn.ibm.com>
> cc: gdb-patches@sourceware.org
>
> Maybe we can do this:
>
> case TYPE_CODE_INT:
> /* There may be some character types that attempt to come
> through as TYPE_CODE_INT since dbxstclass.h is so
> C-oriented, we must change these to "character" from "char". */
>
> if (strcmp (TYPE_NAME (type), "char") == 0)
> fprintfi_filtered (level, stream, "character");
> else
> fprintfi_filtered (level, stream, "integer (%d)", TYPE_LENGTH (type));
> break;
>
> The basic idea is to let the TYPE_CODE (type) and TYPE_LENGTH (type) to
> determine what should be displayed.
This is okay with me. Thanks.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC]: Document patch for F90 derived type support
2006-03-02 4:36 ` Eli Zaretskii
@ 2006-03-02 4:40 ` Daniel Jacobowitz
2006-03-03 9:09 ` Wu Zhou
0 siblings, 1 reply; 23+ messages in thread
From: Daniel Jacobowitz @ 2006-03-02 4:40 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Wu Zhou, gdb-patches
On Thu, Mar 02, 2006 at 06:36:03AM +0200, Eli Zaretskii wrote:
> > Date: Wed, 1 Mar 2006 21:33:35 -0500 (EST)
> > From: Wu Zhou <woodzltc@cn.ibm.com>
> > cc: gdb-patches@sourceware.org
> >
> > Maybe we can do this:
> >
> > case TYPE_CODE_INT:
> > /* There may be some character types that attempt to come
> > through as TYPE_CODE_INT since dbxstclass.h is so
> > C-oriented, we must change these to "character" from "char". */
> >
> > if (strcmp (TYPE_NAME (type), "char") == 0)
> > fprintfi_filtered (level, stream, "character");
> > else
> > fprintfi_filtered (level, stream, "integer (%d)", TYPE_LENGTH (type));
> > break;
> >
> > The basic idea is to let the TYPE_CODE (type) and TYPE_LENGTH (type) to
> > determine what should be displayed.
>
> This is okay with me. Thanks.
Me too, I suppose. If you're going to go this route, take a look at
the full set of types that gfortran prints out useless names for,
please. It's in gcc/fortran/trans-type.c.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC]: Document patch for F90 derived type support
2006-03-02 4:40 ` Daniel Jacobowitz
@ 2006-03-03 9:09 ` Wu Zhou
0 siblings, 0 replies; 23+ messages in thread
From: Wu Zhou @ 2006-03-03 9:09 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Eli Zaretskii, gdb-patches
On Wed, 1 Mar 2006, Daniel Jacobowitz wrote:
> On Thu, Mar 02, 2006 at 06:36:03AM +0200, Eli Zaretskii wrote:
> > > Date: Wed, 1 Mar 2006 21:33:35 -0500 (EST)
> > > From: Wu Zhou <woodzltc@cn.ibm.com>
> > > cc: gdb-patches@sourceware.org
> > >
> > > Maybe we can do this:
> > >
> > > case TYPE_CODE_INT:
> > > /* There may be some character types that attempt to come
> > > through as TYPE_CODE_INT since dbxstclass.h is so
> > > C-oriented, we must change these to "character" from "char". */
> > >
> > > if (strcmp (TYPE_NAME (type), "char") == 0)
> > > fprintfi_filtered (level, stream, "character");
> > > else
> > > fprintfi_filtered (level, stream, "integer (%d)", TYPE_LENGTH (type));
> > > break;
> > >
> > > The basic idea is to let the TYPE_CODE (type) and TYPE_LENGTH (type) to
> > > determine what should be displayed.
> >
> > This is okay with me. Thanks.
>
> Me too, I suppose. If you're going to go this route, take a look at
> the full set of types that gfortran prints out useless names for,
> please. It's in gcc/fortran/trans-type.c.
OK. I will. If I have time, I will see if I can also make a patch
for gfortran. Thanks for the pointer.
Regards
- Wu Zhou
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC]: Document patch for F90 derived type support
2006-03-01 19:38 ` Daniel Jacobowitz
2006-03-02 2:32 ` Wu Zhou
@ 2006-03-02 4:25 ` Eli Zaretskii
2006-03-02 4:27 ` Daniel Jacobowitz
1 sibling, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2006-03-02 4:25 UTC (permalink / raw)
To: gdb-patches
> Date: Wed, 1 Mar 2006 14:38:29 -0500
> From: Daniel Jacobowitz <drow@false.org>
>
> > Perhaps I'm confused: isn't "int4" a 32-bit integer? I thought it
> > was, but if I was mistaken, my apologies for the noise.
>
> It's not reserved at all in the input to the compiler - it might be
> something different than a type, or it might be the name of a record
> type (whatever the correct name for that is).
I'm still not sure I understand, but I think you do agree that this is
a 32-bit integer. In that case, I maintain that we should display
"integer(4)", not "int4".
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC]: Document patch for F90 derived type support
2006-03-02 4:25 ` Eli Zaretskii
@ 2006-03-02 4:27 ` Daniel Jacobowitz
0 siblings, 0 replies; 23+ messages in thread
From: Daniel Jacobowitz @ 2006-03-02 4:27 UTC (permalink / raw)
To: gdb-patches
On Thu, Mar 02, 2006 at 06:25:56AM +0200, Eli Zaretskii wrote:
> > Date: Wed, 1 Mar 2006 14:38:29 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> >
> > > Perhaps I'm confused: isn't "int4" a 32-bit integer? I thought it
> > > was, but if I was mistaken, my apologies for the noise.
> >
> > It's not reserved at all in the input to the compiler - it might be
> > something different than a type, or it might be the name of a record
> > type (whatever the correct name for that is).
>
> I'm still not sure I understand, but I think you do agree that this is
> a 32-bit integer. In that case, I maintain that we should display
> "integer(4)", not "int4".
Sorry, I am not expressing myself well.
The fact that it is named "int4" in debug output doesn't mean that it
is a 32-bit integer. The fact that it is a 32-bit integer, in turn,
may mean that we could choose to ignore its name if that was
worthwhile.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC]: Document patch for F90 derived type support
2006-03-01 2:51 ` Wu Zhou
2006-03-01 4:32 ` Daniel Jacobowitz
@ 2006-03-01 4:51 ` Eli Zaretskii
2006-03-02 2:43 ` Wu Zhou
1 sibling, 1 reply; 23+ messages in thread
From: Eli Zaretskii @ 2006-03-01 4:51 UTC (permalink / raw)
To: Wu Zhou; +Cc: gdb-patches
> Date: Tue, 28 Feb 2006 21:51:24 -0500 (EST)
> From: Wu Zhou <woodzltc@cn.ibm.com>
> cc: gdb-patches@sources.redhat.com
>
> I did some comparison between g77 and gfortran. In the aspect of the
> compiler-generated DW_TAG_base_type, g77 uses "byte", "word" and "integer"
> for "integer*1", "integer*2" and "integer*4" respectively. And gfortran
> seems to adopt a new mechanism, it uses "int1", "int2" and "int4"
> respectively. So it might also make some sense. At lease the debugger
> user can guess the meaning from these words. :-)
So you now think that it is not a good idea to display "integer*4"
instead of "int4"? I thought you previously agreed with me that the
former was better, from the user point of view.
GDB is a debugger. If it were a program to display DWARF-2 debug
info, then it should have displayed exactly what is written in there.
But as a debugger, it should display something that is sensible to the
user of a debugger, i.e. it needs to speak the programming language of
the source, not DWARF.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC]: Document patch for F90 derived type support
2006-03-01 4:51 ` Eli Zaretskii
@ 2006-03-02 2:43 ` Wu Zhou
2006-03-02 3:22 ` Daniel Jacobowitz
2006-03-02 4:37 ` Eli Zaretskii
0 siblings, 2 replies; 23+ messages in thread
From: Wu Zhou @ 2006-03-02 2:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb-patches
On Wed, 1 Mar 2006, Eli Zaretskii wrote:
> > Date: Tue, 28 Feb 2006 21:51:24 -0500 (EST)
> > From: Wu Zhou <woodzltc@cn.ibm.com>
> > cc: gdb-patches@sources.redhat.com
> >
> > I did some comparison between g77 and gfortran. In the aspect of the
> > compiler-generated DW_TAG_base_type, g77 uses "byte", "word" and "integer"
> > for "integer*1", "integer*2" and "integer*4" respectively. And gfortran
> > seems to adopt a new mechanism, it uses "int1", "int2" and "int4"
> > respectively. So it might also make some sense. At lease the debugger
> > user can guess the meaning from these words. :-)
>
> So you now think that it is not a good idea to display "integer*4"
> instead of "int4"? I thought you previously agreed with me that the
> former was better, from the user point of view.
Eli, I am still with you. The former is surely better for the user.
But I am not sure yet which should be fixed, the compiler or the
debugger.
I proposed another method, which depends on TYPE_CODE (type) and
TYPE_LENGTH (type) to determine what to be displayed at last. How do you
think on that? (I sent out that proposal a while ago)
> GDB is a debugger. If it were a program to display DWARF-2 debug
> info, then it should have displayed exactly what is written in there.
> But as a debugger, it should display something that is sensible to the
> user of a debugger, i.e. it needs to speak the programming language of
> the source, not DWARF.
Good stand. I agree with you on this too. :-)
Regards
- Wu Zhou
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC]: Document patch for F90 derived type support
2006-03-02 2:43 ` Wu Zhou
@ 2006-03-02 3:22 ` Daniel Jacobowitz
2006-03-02 4:38 ` Eli Zaretskii
2006-03-02 4:37 ` Eli Zaretskii
1 sibling, 1 reply; 23+ messages in thread
From: Daniel Jacobowitz @ 2006-03-02 3:22 UTC (permalink / raw)
To: Wu Zhou; +Cc: Eli Zaretskii, gdb-patches
On Wed, Mar 01, 2006 at 09:44:07PM -0500, Wu Zhou wrote:
> Eli, I am still with you. The former is surely better for the user.
> But I am not sure yet which should be fixed, the compiler or the
> debugger.
My preference is to fix the compiler rather than the debugger here; it
should output something sensible, and I think the heuristics in the
debugger will be fragile. But, it's up to whoever does the work.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC]: Document patch for F90 derived type support
2006-03-02 3:22 ` Daniel Jacobowitz
@ 2006-03-02 4:38 ` Eli Zaretskii
0 siblings, 0 replies; 23+ messages in thread
From: Eli Zaretskii @ 2006-03-02 4:38 UTC (permalink / raw)
To: Wu Zhou, gdb-patches
> Date: Wed, 1 Mar 2006 22:22:29 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, gdb-patches@sources.redhat.com
>
> My preference is to fix the compiler rather than the debugger here; it
> should output something sensible
Again, the versions of the compiler that are already out there should
not produce wrong types in GDB, IMHO.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFC]: Document patch for F90 derived type support
2006-03-02 2:43 ` Wu Zhou
2006-03-02 3:22 ` Daniel Jacobowitz
@ 2006-03-02 4:37 ` Eli Zaretskii
1 sibling, 0 replies; 23+ messages in thread
From: Eli Zaretskii @ 2006-03-02 4:37 UTC (permalink / raw)
To: Wu Zhou; +Cc: gdb-patches
> Date: Wed, 1 Mar 2006 21:44:07 -0500 (EST)
> From: Wu Zhou <woodzltc@cn.ibm.com>
> cc: gdb-patches@sources.redhat.com
>
> But I am not sure yet which should be fixed, the compiler or the
> debugger.
I think they both should be fixed. Your suggestion to use TYPE_LENGTH
does the right thing for the debugger, I think.
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2006-03-03 1:21 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-02-24 8:13 [RFC]: Document patch for F90 derived type support Wu Zhou
2006-02-24 8:34 ` Eli Zaretskii
2006-02-27 5:59 ` Wu Zhou
2006-02-28 6:43 ` Eli Zaretskii
2006-02-28 15:05 ` Daniel Jacobowitz
2006-02-28 20:09 ` Eli Zaretskii
2006-03-01 2:51 ` Wu Zhou
2006-03-01 4:32 ` Daniel Jacobowitz
2006-03-01 4:53 ` Eli Zaretskii
2006-03-01 5:05 ` Daniel Jacobowitz
2006-03-01 19:02 ` Eli Zaretskii
2006-03-01 19:38 ` Daniel Jacobowitz
2006-03-02 2:32 ` Wu Zhou
2006-03-02 4:36 ` Eli Zaretskii
2006-03-02 4:40 ` Daniel Jacobowitz
2006-03-03 9:09 ` Wu Zhou
2006-03-02 4:25 ` Eli Zaretskii
2006-03-02 4:27 ` Daniel Jacobowitz
2006-03-01 4:51 ` Eli Zaretskii
2006-03-02 2:43 ` Wu Zhou
2006-03-02 3:22 ` Daniel Jacobowitz
2006-03-02 4:38 ` Eli Zaretskii
2006-03-02 4:37 ` Eli Zaretskii
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox