Re: Problems while debugging fortran

Re: Problems while debugging fortran

[Carlos Eduardo Seo]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Joel Brobecker wrote:
> I think that's a great comment. Let's use that one.
> 

All right. Here's the updated patch with Jim's comments. Ok now?

Regards,

- --
Carlos Eduardo Seo
Software Engineer
IBM Linux Technology Center
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHIP5Hqvq7Aov/qQARAg1wAKCKTPmOboGpEXy+4JOYI/t6ky5haQCfTSE4
K7lNORxqXOlJqRSJKSR/ZQk=
=aeaW
-----END PGP SIGNATURE-----

[-- Attachment #2: fortran-main.diff --]
[-- Type: text/x-patch, Size: 1468 bytes --]

2007-10-25  Wu Zhou  <woodzltc@cn.ibm.com>
	    Carlos Eduardo Seo  <cseo@linux.vnet.ibm.com>
	    Jim Blandy  <jimb@codesourcery.com>

	* dwarf2read.c (read_partial_die): check the value
	of DW_AT_calling_convention in Fortran programs.

Index: src/gdb/dwarf2read.c
===================================================================
--- src.orig/gdb/dwarf2read.c
+++ src/gdb/dwarf2read.c
@@ -5616,6 +5616,24 @@ read_partial_die (struct partial_die_inf
         case DW_AT_byte_size:
           part_die->has_byte_size = 1;
           break;
+	case DW_AT_calling_convention:
+	  /* DWARF doesn't provide a way to identify a program's source-level
+	     entry point.  DW_AT_calling_convention attributes are only meant
+	     to describe functions' calling conventions.
+
+	     However, because it's a necessary piece of information in
+	     Fortran, and because DW_CC_program is the only piece of debugging
+	     information whose definition refers to a 'main program' at all,
+	     several compilers have begun marking Fortran main programs with
+	     DW_CC_program --- even when those functions use the standard
+	     calling conventions.
+
+	     So until DWARF specifies a way to provide this information and
+	     compilers pick up the new representation, we'll support this
+	     practice.  */
+	  if ((DW_UNSND (&attr) == DW_CC_program) && (cu->language == language_fortran))
+	    set_main_name (part_die->name);
+	  break;
 	default:
 	  break;
 	}

[-- Attachment #3: fortran-main.diff.sig --]
[-- Type: application/octet-stream, Size: 65 bytes --]

Re: Problems while debugging fortran

[Joel Brobecker]

> 2007-10-25  Wu Zhou  <woodzltc@cn.ibm.com>
> 	    Carlos Eduardo Seo  <cseo@linux.vnet.ibm.com>
> 	    Jim Blandy  <jimb@codesourcery.com>
> 
> 	* dwarf2read.c (read_partial_die): check the value
> 	of DW_AT_calling_convention in Fortran programs.

Just one minor comment:

> +	  if ((DW_UNSND (&attr) == DW_CC_program) && (cu->language == language_fortran))

Could you remove the unnecessary extra parens and split this line
into two (it's too long):

        if (DW_UNSND (&attr) == DW_CC_program
            && cu->language == language_fortran)

Your patch is approved with that adjustment.

Thanks,
-- 
Joel

Re: Problems while debugging fortran

[Carlos Eduardo Seo]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Joel Brobecker wrote:
>
> Just one minor comment:
>
>> +      if ((DW_UNSND (&attr) == DW_CC_program) && (cu->language ==
language_fortran))
>
> Could you remove the unnecessary extra parens and split this line
> into two (it's too long):
>
>         if (DW_UNSND (&attr) == DW_CC_program
>             && cu->language == language_fortran)
>
> Your patch is approved with that adjustment.
>
> Thanks,
Ok, here's the version I commited, with Joel's suggestion and approval.

Regards,

- --
Carlos Eduardo Seo
Software Engineer
IBM Linux Technology Center
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHIQNMqvq7Aov/qQARAlRVAJsEheBLCyh8VdDHPy4Cyg5avI55hACeJxaz
+Y3B2mdbNkmBF9G/gthtq/c=
=xOwT
-----END PGP SIGNATURE-----


[-- Attachment #2: fortran-main.diff --]
[-- Type: text/x-patch, Size: 1472 bytes --]

2007-10-25  Wu Zhou  <woodzltc@cn.ibm.com>
	    Carlos Eduardo Seo  <cseo@linux.vnet.ibm.com>
	    Jim Blandy  <jimb@codesourcery.com>

	* dwarf2read.c (read_partial_die): check the value
	of DW_AT_calling_convention in Fortran programs.

Index: src/gdb/dwarf2read.c
===================================================================
--- src.orig/gdb/dwarf2read.c
+++ src/gdb/dwarf2read.c
@@ -5616,6 +5616,25 @@ read_partial_die (struct partial_die_inf
         case DW_AT_byte_size:
           part_die->has_byte_size = 1;
           break;
+	case DW_AT_calling_convention:
+	  /* DWARF doesn't provide a way to identify a program's source-level
+	     entry point.  DW_AT_calling_convention attributes are only meant
+	     to describe functions' calling conventions.
+
+	     However, because it's a necessary piece of information in
+	     Fortran, and because DW_CC_program is the only piece of debugging
+	     information whose definition refers to a 'main program' at all,
+	     several compilers have begun marking Fortran main programs with
+	     DW_CC_program --- even when those functions use the standard
+	     calling conventions.
+
+	     So until DWARF specifies a way to provide this information and
+	     compilers pick up the new representation, we'll support this
+	     practice.  */
+	  if (DW_UNSND (&attr) == DW_CC_program
+	      && cu->language == language_fortran)
+	    set_main_name (part_die->name);
+	  break;
 	default:
 	  break;
 	}

[-- Attachment #3: fortran-main.diff.sig --]
[-- Type: application/octet-stream, Size: 65 bytes --]

Re: Problems while debugging fortran

[Andreas Schwab]

Carlos Eduardo Seo <cseo@linux.vnet.ibm.com> writes:

> +	  if ((DW_UNSND (&attr) == DW_CC_program) && (cu->language == language_fortran))

Please remove the extra parens and fold the line to keep it below 80
columns.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Problems while debugging fortran

[Joel Brobecker]

[moving to gdb-patches]

> Actually, I was re-reading this thread and I think we can use Wu
> Zhou's patch mentioned before. I've just refreshed it so it applies
> cleanly on CVS head and it's working fine with my Fortran binaries.
> What do you think? Any modifications suggested?


> 2007-10-24  Wu Zhou  <woodzltc@cn.ibm.com>
> 	    Carlos Eduardo Seo  <cseo@linux.vnet.ibm.com>
> 
> 	* dwarf2read.c (read_partial_die): check the value
> 	of DW_AT_calling_convention in Fortran programs.

This is close to what I had in mind, but I would personally prefer
to limit this to Fortran compilation units.  The semantics of this
attribute value are still a bit unclear, and I'd like us to be cautious
in its usage.

-- 
Joel

Re: Problems while debugging fortran

[Carlos Eduardo Seo]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Joel Brobecker wrote:
> [moving to gdb-patches]
>
> This is close to what I had in mind, but I would personally prefer
> to limit this to Fortran compilation units.  The semantics of this
> attribute value are still a bit unclear, and I'd like us to be cautious
> in its usage.
>
Restricted this to Fortran.  Ok to commit now?

- --
Carlos Eduardo Seo
Software Engineer
IBM Linux Technology Center
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHIJixqvq7Aov/qQARAh48AJ48hFyPjN24ewQTVU2QIxOrf4PHwACcD9wk
0G1NiOtDHkaBSQyBhyTnbIg=
=Bh+k
-----END PGP SIGNATURE-----


[-- Attachment #2: fortran-main.diff --]
[-- Type: text/x-patch, Size: 878 bytes --]

2007-10-25  Wu Zhou  <woodzltc@cn.ibm.com>
	    Carlos Eduardo Seo  <cseo@linux.vnet.ibm.com>

	* dwarf2read.c (read_partial_die): check the value
	of DW_AT_calling_convention in Fortran programs.

Index: src/gdb/dwarf2read.c
===================================================================
--- src.orig/gdb/dwarf2read.c
+++ src/gdb/dwarf2read.c
@@ -5616,6 +5616,13 @@ read_partial_die (struct partial_die_inf
         case DW_AT_byte_size:
           part_die->has_byte_size = 1;
           break;
+	case DW_AT_calling_convention:
+	  /* DWARF standard suggests to use value DW_CC_program of attribute
+	   DW_AT_calling_convention to indicate the Fortran main program.
+	   The following code is to check this.  */
+	  if ((DW_UNSND (&attr) == DW_CC_program) && (cu->language == language_fortran))
+	    set_main_name (part_die->name);
+	  break;
 	default:
 	  break;
 	}

[-- Attachment #3: fortran-main.diff.sig --]
[-- Type: application/octet-stream, Size: 65 bytes --]

Re: Problems while debugging fortran

[Jim Blandy]

Carlos Eduardo Seo <cseo at linux.vnet.ibm.com> writes:
> Joel Brobecker wrote:
>> [moving to gdb-patches]
>>
>> This is close to what I had in mind, but I would personally prefer
>> to limit this to Fortran compilation units.  The semantics of this
>> attribute value are still a bit unclear, and I'd like us to be cautious
>> in its usage.
>>
> Restricted this to Fortran.  Ok to commit now?
>
> --
> Carlos Eduardo Seo
> Software Engineer
> IBM Linux Technology Center
> 2007-10-25  Wu Zhou  <woodzltc@cn.ibm.com>
> 	    Carlos Eduardo Seo  <cseo@linux.vnet.ibm.com>
>
> 	* dwarf2read.c (read_partial_die): check the value
> 	of DW_AT_calling_convention in Fortran programs.
>
> Index: src/gdb/dwarf2read.c
> ===================================================================
> --- src.orig/gdb/dwarf2read.c
> +++ src/gdb/dwarf2read.c
> @@ -5616,6 +5616,13 @@ read_partial_die (struct partial_die_inf
>          case DW_AT_byte_size:
>            part_die->has_byte_size = 1;
>            break;
> +	case DW_AT_calling_convention:
> +	  /* DWARF standard suggests to use value DW_CC_program of attribute
> +	   DW_AT_calling_convention to indicate the Fortran main program.
> +	   The following code is to check this.  */

This comment isn't right.  The Fortran main program expects to have
its arguments passed to it differently than other subroutines or
functions; that's what DW_AT_calling_convention is meant to express.
The comment should say something like:

  /* DWARF doesn't provide a way to identify a program's entry point.
     However, the Fortran main program receives its arguments via a
     special calling convention; we look for that to recognize the
     program's entry point.  */

Re: Problems while debugging fortran

[Daniel Jacobowitz]

On Thu, Oct 25, 2007 at 08:30:38AM -0700, Jim Blandy wrote:
> This comment isn't right.  The Fortran main program expects to have
> its arguments passed to it differently than other subroutines or
> functions; that's what DW_AT_calling_convention is meant to express.
> The comment should say something like:
> 
>   /* DWARF doesn't provide a way to identify a program's entry point.
>      However, the Fortran main program receives its arguments via a
>      special calling convention; we look for that to recognize the
>      program's entry point.  */

Have we concluded that this is true?  If so, is there any reason we
should not make gfortran generate this attribute?  And if so, why
not GNAT or GCJ too?

The only thing we risk (that I can think of) in treating DW_CC_program
as a marker for main is that if the architecture required
DW_CC_program to indicate calling convention on a per-function basis
we would fail to implement "print main()" correctly.  I don't think
that matters.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Problems while debugging fortran

[Carlos Eduardo Seo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Daniel Jacobowitz wrote:
> On Thu, Oct 25, 2007 at 08:30:38AM -0700, Jim Blandy wrote:
>> This comment isn't right.  The Fortran main program expects to have
>> its arguments passed to it differently than other subroutines or
>> functions; that's what DW_AT_calling_convention is meant to express.
>> The comment should say something like:
>>
>>   /* DWARF doesn't provide a way to identify a program's entry point.
>>      However, the Fortran main program receives its arguments via a
>>      special calling convention; we look for that to recognize the
>>      program's entry point.  */
>
> Have we concluded that this is true?  If so, is there any reason we
> should not make gfortran generate this attribute?  And if so, why
> not GNAT or GCJ too?
>
> The only thing we risk (that I can think of) in treating DW_CC_program
> as a marker for main is that if the architecture required
> DW_CC_program to indicate calling convention on a per-function basis
> we would fail to implement "print main()" correctly.  I don't think
> that matters.
>
The DWARF3 spec says:

'If the semantics of the language of the compilation unit containing
the subroutine entry distinguishes between ordinary subroutines and
subroutines that can serve as the "main program", that is, subroutines
that cannot be called directly according to the ordinary calling
conventions, then the debugging information entry for such a
subroutine _may_ have a calling convention attribute whose value is
the constant DW_CC_program.

The DW_CC_program value is intended to support Fortran main programs.
It is not intended as a way of finding the entry address for the program.'

So, it's a suggestion by the DWARF spec. I was investigating the DWARF
info generated by gfortran and found out that this compiler doesn't
generate DW_AT_calling_convention. Instead, it replaces the name of
the "main program" by MAIN__ . Therefore, I think we should restrict
this only to XLF.

What's your opinion?


- --
Carlos Eduardo Seo
Software Engineer
IBM Linux Technology Center
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHIMD1qvq7Aov/qQARAl46AJ9ODvLeHzL2rpcwvXMWVzpLxmaM1wCfePEN
XFp9dC4zv7b7ChzwKUcQyRk=
=6NPq
-----END PGP SIGNATURE-----

Re: Problems while debugging fortran

[Jim Blandy]

Daniel Jacobowitz <drow at false.org> writes:
> On Thu, Oct 25, 2007 at 08:30:38AM -0700, Jim Blandy wrote:
>> This comment isn't right.  The Fortran main program expects to have
>> its arguments passed to it differently than other subroutines or
>> functions; that's what DW_AT_calling_convention is meant to express.
>> The comment should say something like:
>> 
>>   /* DWARF doesn't provide a way to identify a program's entry point.
>>      However, the Fortran main program receives its arguments via a
>>      special calling convention; we look for that to recognize the
>>      program's entry point.  */
>
> Have we concluded that this is true?  If so, is there any reason we
> should not make gfortran generate this attribute?  And if so, why
> not GNAT or GCJ too?

We've been discussing this on the DWARF committee.  That attribute is
definitely not meant to be used to recognize the Fortran main program.
There's a proposal for an attribute that really does what we want, but
it's been sent back for revision.

Re: Problems while debugging fortran

[Daniel Jacobowitz]

On Thu, Oct 25, 2007 at 09:18:14AM -0700, Jim Blandy wrote:
> We've been discussing this on the DWARF committee.  That attribute is
> definitely not meant to be used to recognize the Fortran main program.
> There's a proposal for an attribute that really does what we want, but
> it's been sent back for revision.

This is, if you will forgive my saying so, a bit absurd.  I think
we've been discussing this problem for three or four years now and
we're still waiting for a new and more accurate attribute.  I hope
there's at least some clarification of the text for DW_CC_program
included; if it's not for the entry point, and it's not for the
Fortran main program, I have no idea what it's for.

I see that FX is considering implementing it for gfortran now.

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10220

-- 
Daniel Jacobowitz
CodeSourcery

Re: Problems while debugging fortran

[Jim Blandy]

Daniel Jacobowitz <drow at false.org> writes:
> On Thu, Oct 25, 2007 at 09:18:14AM -0700, Jim Blandy wrote:
>> We've been discussing this on the DWARF committee.  That attribute is
>> definitely not meant to be used to recognize the Fortran main program.
>> There's a proposal for an attribute that really does what we want, but
>> it's been sent back for revision.
>
> This is, if you will forgive my saying so, a bit absurd.  I think
> we've been discussing this problem for three or four years now and
> we're still waiting for a new and more accurate attribute.  I hope
> there's at least some clarification of the text for DW_CC_program
> included; if it's not for the entry point, and it's not for the
> Fortran main program, I have no idea what it's for.

I do forgive your saying so.  :)  I'm just the messenger, okay?

The committee wanted language that would be clear in all sorts of
hairy corner cases: What about Java, where the entry point isn't
selected until link time?  What about Ada, where every module can have
its own main, and they all get run in some order?  What about global
constructors in C++ --- they're the first user code that gets
executed?  What about COBOL, where I fell asleep?

Why not just make up a GNU extension that does what we want?  It'd be
trivial.

As far as what the attribute is supposed to mean, it seems pretty
obvious.  A language might specify different calling conventions for
different functions; if present, the attribute specifies the calling
convention used for the function it's attached to.  If a Fortran
program had multiple entry points (I think the language permits this,
although I'm not sure what it would mean in Unix), the compiler could
legitimately attach that attribute to all of them, even though only
one of them was serving as the program's entry point.

Re: Problems while debugging fortran

[Joel Brobecker]

> The committee wanted language that would be clear in all sorts of
> hairy corner cases: What about Java, where the entry point isn't
> selected until link time?  What about Ada, where every module can have
> its own main, and they all get run in some order?  What about global
> constructors in C++ --- they're the first user code that gets
> executed?  What about COBOL, where I fell asleep?

Yeah, the case of Ada is a bit particular, because the entry point
and the main procedures are completely distinct. There is no way that
the *compiler* knows whether one procedure is going to be the "main"
or not for a given program. In fact, the same unit, compiled once,
can be used as the main in one program, and as a simple procedure
that you call in another program. Because of that, I'm not sure
that a DWARF-based solution to encoding the name of the main procedure
is practical.

-- 
Joel

Re: Problems while debugging fortran

[Joel Brobecker]

> > +	case DW_AT_calling_convention:
> > +	  /* DWARF standard suggests to use value DW_CC_program of attribute
> > +	   DW_AT_calling_convention to indicate the Fortran main program.
> > +	   The following code is to check this.  */
> 
> This comment isn't right.  The Fortran main program expects to have
> its arguments passed to it differently than other subroutines or
> functions; that's what DW_AT_calling_convention is meant to express.
> The comment should say something like:
> 
>   /* DWARF doesn't provide a way to identify a program's entry point.
>      However, the Fortran main program receives its arguments via a
>      special calling convention; we look for that to recognize the
>      program's entry point.  */

I agree with Jim's comment, but on the other hand, I propose a slightly
different way of saying this:

   /* In Fortran programs compiled with XLF, the only way we have found
      so far to identify the main procedure is by using the fact that
      the calling convention is different from the other procedures:
      The DW_AT_calling_convention attribute is set to DW_CC_program.

      This is not the intent of this attribute as documented in the
      DWARF standard, but we haven't found any other distinctive
      characteristic of the main procedure, so we check the calling
      convention for Fortran compilation units.  */

I want to steer away from the concept of "entry point", because the
main is not necessarily the entry point. For instance, in Ada, the
entry point is distinct from the main procedure.

Is Carlos Eduado's patch OK with the comment I suggest?

-- 
Joel

Re: Problems while debugging fortran

[Jim Blandy]

Joel Brobecker <brobecker at adacore.com> writes:
> I agree with Jim's comment, but on the other hand, I propose a slightly
> different way of saying this:
>
>    /* In Fortran programs compiled with XLF, the only way we have found
>       so far to identify the main procedure is by using the fact that
>       the calling convention is different from the other procedures:
>       The DW_AT_calling_convention attribute is set to DW_CC_program.
>
>       This is not the intent of this attribute as documented in the
>       DWARF standard, but we haven't found any other distinctive
>       characteristic of the main procedure, so we check the calling
>       convention for Fortran compilation units.  */
>
> I want to steer away from the concept of "entry point", because the
> main is not necessarily the entry point. For instance, in Ada, the
> entry point is distinct from the main procedure.
>
> Is Carlos Eduado's patch OK with the comment I suggest?

This would be fine with me, too.

Re: Problems while debugging fortran

[Daniel Jacobowitz]

On Thu, Oct 25, 2007 at 12:30:41PM -0700, Jim Blandy wrote:
> This would be fine with me, too.

Me too.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Problems while debugging fortran

[Carlos Eduardo Seo]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel Jacobowitz wrote:
> On Thu, Oct 25, 2007 at 12:30:41PM -0700, Jim Blandy wrote:
>> This would be fine with me, too.
> 
> Me too.
> 

Ok. I added Joel's comments to the patch, replacing the original ones.
If no one has any other objections, I can commit this later.

Regards,


- --
Carlos Eduardo Seo
Software Engineer
IBM Linux Technology Center
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHIPF+qvq7Aov/qQARAjcnAJ0SBFHaOnQrkzN2C0hsKuuYr5bhLQCeJLMS
OI9Fa1ZuhUQ7/h9lV19q86w=
=+biI
-----END PGP SIGNATURE-----

[-- Attachment #2: fortran-main.diff --]
[-- Type: text/x-patch, Size: 1282 bytes --]

2007-10-25  Wu Zhou  <woodzltc@cn.ibm.com>
	    Carlos Eduardo Seo  <cseo@linux.vnet.ibm.com>
	    Joel Brobecker  <brobecker@adacore.com>

	* dwarf2read.c (read_partial_die): check the value
	of DW_AT_calling_convention in Fortran programs.

Index: src/gdb/dwarf2read.c
===================================================================
--- src.orig/gdb/dwarf2read.c
+++ src/gdb/dwarf2read.c
@@ -5616,6 +5616,19 @@ read_partial_die (struct partial_die_inf
         case DW_AT_byte_size:
           part_die->has_byte_size = 1;
           break;
+	case DW_AT_calling_convention:
+	  /* In Fortran programs compiled with XLF, the only way we have found
+	     so far to identify the main procedure is by using the fact that
+	     the calling convention is different from the other procedures:
+	     The DW_AT_calling_convention attribute is set to DW_CC_program.
+
+	     This is not the intent of this attribute as documented in the
+	     DWARF standard, but we haven't found any other distinctive
+	     characteristic of the main procedure, so we check the calling
+	     convention for Fortran compilation units.  */
+	  if ((DW_UNSND (&attr) == DW_CC_program) && (cu->language == language_fortran))
+	    set_main_name (part_die->name);
+	  break;
 	default:
 	  break;
 	}

[-- Attachment #3: fortran-main.diff.sig --]
[-- Type: application/octet-stream, Size: 65 bytes --]