Re: Problems while debugging fortran

Re: Problems while debugging fortran

[François-Xavier Coudert]

Hi,

> This is very unclear, since they don't explain what "support"
> refers to. But for people stuck with XLF, if we can improve their
> lives without hurting the rest of GDB, I'm ok with compromising and
> using this attribute value be used to find the main.

I'd like to support this comprise, and I'll note that other compilers
(Intel and Sun, at least) already use this convention.

For the longer term, what do you think is the optimal solution? I'd
like to make gfortran, the Fortran front-end in GCC, do The Right
Thing, but what is it? Should we add this DW_AT_calling_convention tag
for the time being, until the meaning of the DWARF standard is made
clearer?

FX

PS: I might submit patches to GDB in the future. Could someone send me
copyright assignment form? (I already have a GCC assignment, if that
makes any difference)

Re: Problems while debugging fortran

[Daniel Jacobowitz]

On Thu, Oct 25, 2007 at 05:06:54PM +0100, Fran?ois-Xavier Coudert wrote:
> For the longer term, what do you think is the optimal solution? I'd
> like to make gfortran, the Fortran front-end in GCC, do The Right
> Thing, but what is it? Should we add this DW_AT_calling_convention tag
> for the time being, until the meaning of the DWARF standard is made
> clearer?

I'll let Jim answer this, though I think it's reasonable.

> PS: I might submit patches to GDB in the future. Could someone send me
> copyright assignment form? (I already have a GCC assignment, if that
> makes any difference)

Sure, I will.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Problems while debugging fortran

[Jim Blandy]

Daniel Jacobowitz <drow at false.org> writes:
> On Thu, Oct 25, 2007 at 05:06:54PM +0100, Fran?ois-Xavier Coudert wrote:
>> For the longer term, what do you think is the optimal solution? I'd
>> like to make gfortran, the Fortran front-end in GCC, do The Right
>> Thing, but what is it? Should we add this DW_AT_calling_convention tag
>> for the time being, until the meaning of the DWARF standard is made
>> clearer?
>
> I'll let Jim answer this, though I think it's reasonable.

To be clear: I think the actual code in Carlos's patch is just fine.
The comment, though, should not say things that are simply untrue.
Which is why I suggested a new comment, instead of rejecting the
patch.  Whether or not we like the state of DWARF in this regard, the
comment should correct describes the state of play, no?

Re: Problems while debugging fortran

[Daniel Jacobowitz]

On Thu, Oct 25, 2007 at 11:43:57AM -0700, Jim Blandy wrote:
> To be clear: I think the actual code in Carlos's patch is just fine.
> The comment, though, should not say things that are simply untrue.
> Which is why I suggested a new comment, instead of rejecting the
> patch.  Whether or not we like the state of DWARF in this regard, the
> comment should correct describes the state of play, no?

  However, the Fortran main program receives its arguments via a
  special calling convention

I don't think that's true.  As far as I know it has a perfectly
ordinary calling convention.

As for Carlos's comment, I don't know if it's true or not, but
it certainly seems to be what everyone else interprets the
DWARF standard to suggest :-)

-- 
Daniel Jacobowitz
CodeSourcery

Re: Problems while debugging fortran

[Jim Blandy]

Here's a revised comment that may explain what's going on better:

  /* 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.  */

Re: Problems while debugging fortran

[Joel Brobecker]

> Here's a revised comment that may explain what's going on better:
> 
>   /* 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.  */

I think that's a great comment. Let's use that one.

-- 
Joel

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

[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 -- DWARF

[Michael Eager]

Hi --

I haven't been following this thread and was just told about it.
Disclaimer:  I haven't read all of the discussion about this issue.

The DWARF Committee has been considering a couple different
proposals for an extension to DWARF to identify the "main" routine
for Fortran or other languages which need this.  An early version of
the proposal can be found on the DWARF website:
http://dwarfstd.org/Issues.php.  A revised proposal which will
have an attribute in the Compilation Unit DIE which points to the
"main" subprogram is under development.

Carlos Eduardo Seo wrote:
> -----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-----
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 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;
>  	}


-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: Problems while debugging fortran

[Carlos Eduardo Seo]

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

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



Carlos Eduardo Seo wrote:
>
>
> Daniel Jacobowitz wrote:
>> Yes, this does seem sensible.
>
> Great, I can come up with a patch shortly.
>
> Regards,
>

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?

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

iD8DBQFHH7+eqvq7Aov/qQARAjNoAJ4hHCpEk9u1+gW/B5uVen+Rq0XWLwCeJ+9z
KjKTK0t2acXQaM+HbLkT6/Y=
=UjNN
-----END PGP SIGNATURE-----


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

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.

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)
+	    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

[Carlos Eduardo Seo]

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



Daniel Jacobowitz wrote:
> On Wed, Oct 24, 2007 at 12:33:36PM -0700, Joel Brobecker wrote:
>> Question to the other GDB contributors/maintainers: Is it going to
>> hurt GDB if we fallback to using "DW_AT_calling_convention =
>> DW_CC_program" to find the main? The DWARF3 manual says that this
>> attribute value was <<intended to support Fortran main programs>>.
>> This is very unclear, since they don't explain what "support"
>> refers to. But for people stuck with XLF, if we can improve their
>> lives without hurting the rest of GDB, I'm ok with compromising and
>> using this attribute value be used to find the main.
>
> Yes, this does seem sensible.
>
Great, I can come up with a patch shortly.

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

iD8DBQFHH6gQqvq7Aov/qQARAqtMAJsGCQ0/78OVWVih/pDeuiI7v/JoBACeMROe
L3EmicoHS4bLQklrxVtitIw=
=eb45
-----END PGP SIGNATURE-----

Re: Problems while debugging fortran

[Daniel Jacobowitz]

On Wed, Oct 24, 2007 at 12:33:36PM -0700, Joel Brobecker wrote:
> Question to the other GDB contributors/maintainers: Is it going to
> hurt GDB if we fallback to using "DW_AT_calling_convention =
> DW_CC_program" to find the main? The DWARF3 manual says that this
> attribute value was <<intended to support Fortran main programs>>.
> This is very unclear, since they don't explain what "support"
> refers to. But for people stuck with XLF, if we can improve their
> lives without hurting the rest of GDB, I'm ok with compromising and
> using this attribute value be used to find the main.

Yes, this does seem sensible.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Problems while debugging fortran

[Joel Brobecker]

> The compiler is XLF and the only way it tags the "main" function is by
> adding DW_AT_calling_convention = DW_CC_program. Unfortunately, I
> don't have any control over the compiler, so I'm stuck with this. Any
> other thoughts?

Apart from using "DW_AT_calling_convention = DW_CC_program", not much, no.
The idea is to try to find something that is unique to the main function.
Sometimes it's the naming of the function, but it could be something else.

Question to the other GDB contributors/maintainers: Is it going to
hurt GDB if we fallback to using "DW_AT_calling_convention =
DW_CC_program" to find the main? The DWARF3 manual says that this
attribute value was <<intended to support Fortran main programs>>.
This is very unclear, since they don't explain what "support"
refers to. But for people stuck with XLF, if we can improve their
lives without hurting the rest of GDB, I'm ok with compromising and
using this attribute value be used to find the main.

-- 
Joel

Re: Problems while debugging fortran

[Carlos Eduardo Seo]

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

Joel Brobecker wrote:
>
> Unfortunately, this is an idea that has already been discussed a
> couple of years ago, and people felt that this was not the intent
> of that attribute. See:
>
> http://www.cygwin.com/ml/gdb-patches/2005-11/msg00380.html
>
> I haven't followed any development on the DWARF3 side whether
> something more appropriate has been introduced for that purpose.
>
> What compiler are you using? Do you have any control on what your
> compiler does? Perhaps you can add an extra symbol like we do with
> the Ada compiler? Just some thoughts...
The compiler is XLF and the only way it tags the "main" function is by
adding DW_AT_calling_convention = DW_CC_program. Unfortunately, I
don't have any control over the compiler, so I'm stuck with this. Any
other thoughts?

Thanks and 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

iD8DBQFHH3C/qvq7Aov/qQARAldZAJ4kQSm43hBsKggHPurQ6HLAjbwN6gCeP+lX
VpHrh1Pt3tETq78AWNFoPZc=
=9/uV
-----END PGP SIGNATURE-----

RE: Problems while debugging fortran

[Pierre Muller]

  I am about to commit a similar patch to
recognize the special symbol name used
by GNU pascal compiler.
  I tought about adding a check for
current_language == language_pascal,
but the language is only set if the
program is compiled with debug information
on (will be the case most of the time),
but also only if the main source is recognized
as a pascal source.

  Currently, '.inc', '.p', '.pp' and '.pas'
suffixes are recognized as pascal sources,
but Delphi uses '.dpr' so chances are that
you compile a source that will not be recognized 
as a pascal source and in that case, the
pascal_main_name would not be called at all.

  
Pierre Muller
pascal language maintainer

> -----Original Message-----
> From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On
> Behalf Of Carlos Eduardo Seo
> Sent: Wednesday, September 26, 2007 11:38 PM
> To: Daniel Jacobowitz
> Cc: gdb@sourceware.org; brobecker@adacore.com
> Subject: Re: Problems while debugging fortran
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Daniel Jacobowitz wrote:
> >
> > Here's a relevant patch from the Debian packages of GDB.  As you can
> > see it comes from a mailing list message - I don't remember exactly
> > who submitted it without looking it up and I don't remember exactly
> > why it was never committed, but it was probably Wu Zhou and it was
> > probably never merged because of the larger issue of symbol case
> > sensitivity.
> This patch works fine _if_ the compiler is gfortran/g77. However, not
> all compilers call the program by "MAIN__". So, I was thinking about
> having something in symtab.c:find_main_name that checks DW_CC_program
> value if the language is Fortran and get the name from the main
> routine from DW_AT_name. Is that an acceptable solution?
> 
> 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
> 
> iD8DBQFG+tE1qvq7Aov/qQARAprFAJ0aijQ2D6Mhuc4e4mGr/y1VAskdfgCfQeXT
> /47+1mSHn6XRATG0ihLyUo0=
> =DbGQ
> -----END PGP SIGNATURE-----

Re: Problems while debugging fortran

[Joel Brobecker]

> > Here's a relevant patch from the Debian packages of GDB.  As you can
> > see it comes from a mailing list message - I don't remember exactly
> > who submitted it without looking it up and I don't remember exactly
> > why it was never committed, but it was probably Wu Zhou and it was
> > probably never merged because of the larger issue of symbol case
> > sensitivity.
> This patch works fine _if_ the compiler is gfortran/g77. However, not
> all compilers call the program by "MAIN__". So, I was thinking about
> having something in symtab.c:find_main_name that checks DW_CC_program
> value if the language is Fortran and get the name from the main
> routine from DW_AT_name. Is that an acceptable solution?

Unfortunately, this is an idea that has already been discussed
a couple of years ago, and people felt that this was not the
intent of that attribute. See:

   http://www.cygwin.com/ml/gdb-patches/2005-11/msg00380.html

I haven't followed any development on the DWARF3 side whether
something more appropriate has been introduced for that purpose.

What compiler are you using? Do you have any control on what
your compiler does? Perhaps you can add an extra symbol like
we do with the Ada compiler? Just some thoughts...

-- 
Joel

Re: Problems while debugging fortran

[Carlos Eduardo Seo]

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

Daniel Jacobowitz wrote:
>
> Here's a relevant patch from the Debian packages of GDB.  As you can
> see it comes from a mailing list message - I don't remember exactly
> who submitted it without looking it up and I don't remember exactly
> why it was never committed, but it was probably Wu Zhou and it was
> probably never merged because of the larger issue of symbol case
> sensitivity.
This patch works fine _if_ the compiler is gfortran/g77. However, not
all compilers call the program by "MAIN__". So, I was thinking about
having something in symtab.c:find_main_name that checks DW_CC_program
value if the language is Fortran and get the name from the main
routine from DW_AT_name. Is that an acceptable solution?

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

iD8DBQFG+tE1qvq7Aov/qQARAprFAJ0aijQ2D6Mhuc4e4mGr/y1VAskdfgCfQeXT
/47+1mSHn6XRATG0ihLyUo0=
=DbGQ
-----END PGP SIGNATURE-----

Re: Problems while debugging fortran

[Joel Brobecker]

> If I change the name of my Fortran program to "main", I can set a
> breakpoint by line number inside it. So it seems that GDB is only
> looking for "main". This is fine for C, [...]

Exactly.

> [..] but it won't work for Fortran IMHO, not even using that patch
> Daniel posted. So, I believe we should address this issue in
> symtab.c:find_main_name. I can start looking into it.

That's what I was trying to say.

To give you a bit more context, let me give you a few more datapoints.
This is as much as I will be able to help you, because I do not know
Fortran at all.

First of all, I think the term "main" is a bit overloaded in our discussion.
There is what we usually call the "main program", which is the routine
that gets called to start our program. And then there is the function
whose name is "main". In languages such as C, the "main program" will
always be called "main". But on the other hand, in Ada, the main program
can be called anything.

Let's develop a bit more the Ada case. Consider the following simplistic
program that does pretty much nothing:

        procedure Foo is
        begin
           null;
        end Foo;

We can make this procedure our "main program". To do that, we build
the program using the following command:

        % gnatmake -g foo

(gnatmake is the equivalent of "make" except that it computes the
dependencies automatically)

Now, how does the debugger find out that, in this case, the main
routine name is procedure "Foo"? It knows that the Ada compiler
in GCC generates a symbol whose name is well known, that points
to a string containing the full name of our main routine. Check
out ada-lang.c:ada_main_name(). So if we find our symbol, then
we know the main procedure is in Ada, and what its name is.

I am hoping that the Fortran compiler does something similar,
that it leaves a mark of some kind that will allow you to determine
what the main routine name is.

> In the scenario above, a breakpoint by line number inside a function
> will fail. I think this may has to do with the compiler generating two
> DWARF compilation units (one for "main" and other for the function)
> and GDB is not reading the one related to the function. What are your
> thoughts about this?

I'm hoping that the description above makes it clearer for you what
needs to be done. I am a bit lost in your particular example, simply
because I don't know what the Fortran compiler actually does...

-- 
Joel

Re: Problems while debugging fortran

[Carlos Eduardo Seo]

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

Joel Brobecker wrote:
>
> I wonder why that is. Is this the file where function "main" is
> reported to be?
>
Yes, it seems that way. The problem is: in that sample code I sent in
my first post, there's no function "main".  If GDB assumes that it
will always be like:

program main
    ...blah blah
end

it'll never work for something like:

program foo
    ... blah blah
end

If I change the name of my Fortran program to "main", I can set a
breakpoint by line number inside it. So it seems that GDB is only
looking for "main". This is fine for C, but it won't work for Fortran
IMHO, not even using that patch Daniel posted. So, I believe we should
address this issue in symtab.c:find_main_name. I can start looking
into it.

In the scenario above, a breakpoint by line number inside a function
will fail. I think this may has to do with the compiler generating two
DWARF compilation units (one for "main" and other for the function)
and GDB is not reading the one related to the function. What are your
thoughts about this?

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

iD4DBQFG+UOZqvq7Aov/qQARAgXlAJ0fa3E/Dv15WNFHB9s0uODC/YUKXQCY1xhJ
9jNxJPlD98kMq1XIuFE6pA==
=3bWB
-----END PGP SIGNATURE-----

Re: Problems while debugging fortran

[Joel Brobecker]

> > I think Daniel was right on the spot. You are trying to use the
> > "current source file" concept right at the start of your session
> > assuming that it is automatically set to the source file where
> > you main is defined. Is that correct?
> Yes. And the problem is that the current file is set as "init.c".

I wonder why that is. Is this the file where function "main" is
reported to be?

> > We can certainly work on modifying GDB to be
> > better at finding the name of the main procedure in a Fortran program
> > (just like we do with Ada programs).
> Any ideas where can we start?

In terms of the GDB implementation, you can start by looking at what
we do in symtab.c:find_main_name(). What you need to do is find a way
for GDB to determine what the name of the main routine is. See the
comment I inserted that explains also that we should not have any
false positive.

In terms of the Fortran compiler, I don't know how things are setup,
so I don't know how it actually needs to be done, or if it's doable
at all, actually.  It looks like, from the patch that Daniel posted,
that this routine is always called "MAIN__". Is that the case?

-- 
Joel

Re: Problems while debugging fortran

[Carlos Eduardo Seo]

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

Joel Brobecker wrote:
>
> I think Daniel was right on the spot. You are trying to use the
> "current source file" concept right at the start of your session
> assuming that it is automatically set to the source file where
> you main is defined. Is that correct?
Yes. And the problem is that the current file is set as "init.c".
>
> Unfortunately, I think this feature only works well for Ada and C
> as far as I can tell from the code.  Does the patch that Daniel posted
> earlier help in your case?
No, unfortunately it doesn't.

> We can certainly work on modifying GDB to be
> better at finding the name of the main procedure in a Fortran program
> (just like we do with Ada programs).
Any ideas where can we start?

Thanks and 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

iD8DBQFG+B4Lqvq7Aov/qQARAg8xAJ9NJbMZhZynj2sHhO55mkW+cycrbACggA4q
zN8lJUn/Utp/6RhzcLrtt6U=
=n7sA
-----END PGP SIGNATURE-----

Re: Problems while debugging fortran

[Joel Brobecker]

> As you can see, breakpoints by line number don't work. However, if I
> use the function name, it works correctly.

I think Daniel was right on the spot. You are trying to use the
"current source file" concept right at the start of your session
assuming that it is automatically set to the source file where
you main is defined. Is that correct?

Unfortunately, I think this feature only works well for Ada and C
as far as I can tell from the code.  Does the patch that Daniel posted
earlier help in your case? We can certainly work on modifying GDB to be
better at finding the name of the main procedure in a Fortran program
(just like we do with Ada programs).

In the meantime, you'll have to force the current source file name
to be your test.f by doing a "list" of that file first.

-- 
Joel

Re: Problems while debugging fortran

[Carlos Eduardo Seo]

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


Joel Brobecker wrote:
>
> It should be the same if the "current file" is set to test.f.
> It looks like it isn't. For some reason, GDB thinks that the current
> file is something else. Again, perhaps a copy of your GDB session
> might give a clue.
>
Here's a sample output with some comments:

(gdb) b 25
No line 25 in file "init.c".
(gdb) b this
Breakpoint 1 at 0x10000670: file /tst111/ptr/fxdb1251.f, line 25.
(gdb) b 31
No line 31 in file "init.c".
(gdb) b ifunc
Breakpoint 2 at 0x10000770: file /tst111/ptr/fxdb1251.f, line 30.

As you can see, breakpoints by line number don't work. However, if I
use the function name, it works correctly.
At this point, if I clear all breakpoints and try to set them again by
line number, it doesn't work. Now, if I run the program, this happens:

(gdb) r
Starting program: /home/cseo/gdb-bugs/pr36275/fxdb1251
[Thread debugging using libthread_db enabled]
[New Thread 0xf7fb9000 (LWP 16185)]
[Switching to Thread 0xf7fb9000 (LWP 16185)]

Breakpoint 1, this () at /tst111/ptr/fxdb1251.f:25
25              i=ifunc(1)
Current language:  auto; currently fortran
(gdb) c
Continuing.

Breakpoint 2, ifunc (i=
During symbol reading, incomplete CFI data; unspecified registers
(e.g., r0) at 0x100007dc.
1) at /tst111/ptr/fxdb1251.f:30
30              print *,i*2
(gdb) c
Continuing.
 2
 1

Program exited normally.
(gdb) del
Delete all breakpoints? (y or n) y
(gdb) b 25
Breakpoint 3 at 0x10000670: file /tst111/ptr/fxdb1251.f, line 25.
(gdb) b 31
Breakpoint 4 at 0x100007cc: file /tst111/ptr/fxdb1251.f, line 31.
(gdb)

After running the program, if I clear all breakpoints and try to set
them again by line number, it works.

Any ideas?

Thanks and 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

iD8DBQFG9dE8qvq7Aov/qQARAnoGAJ9oAM2QSypensiZxsv1fJBvnucUQACfSWFD
zbU+0hlFgADSvx1JGGzkU3E=
=m8M+
-----END PGP SIGNATURE-----

Re: Problems while debugging fortran

[Daniel Jacobowitz]

On Thu, Sep 20, 2007 at 01:46:22PM -0700, Joel Brobecker wrote:
> > No, just "break <linenumber>". However, I tried your command and it
> > worked. Why? Shouldn't the behavior be the same in both cases?
> 
> It should be the same if the "current file" is set to test.f.
> It looks like it isn't. For some reason, GDB thinks that the current
> file is something else. Again, perhaps a copy of your GDB session
> might give a clue.

Here's a relevant patch from the Debian packages of GDB.  As you can
see it comes from a mailing list message - I don't remember exactly
who submitted it without looking it up and I don't remember exactly
why it was never committed, but it was probably Wu Zhou and it was
probably never merged because of the larger issue of symbol case
sensitivity.

-- 
Daniel Jacobowitz
CodeSourcery

Daniel,

Although the proper way of adding case insensitivity to symbol lookup is 
still under discussion, I think it might be desirable to set the main 
function of Fortran programs to "MAIN__" first.  Because it can at least 
let GDB recognize that the language is Fortran after loading a Fortran 
executable only.  What is your idea on this?  Please comments.  TIA!

Here is the patch to set the main function in Fortran programs to 
"MAIN__".  And followed is a patch to verify this.  Tested with g77 and 
gfortran on x86, and g77 on ppc64.  With the first patch, it reported 
PASS; without, report FAIL.  No regression is found in gdb.fortran 
testcases.  

P.S: if there is a symbol named "MAIN__" in sources of other languages, it 
might disturb the debugging.  But I am not sure how much it is.

---
 gdb/symtab.c                       |    8 +++++--
 gdb/testsuite/gdb.fortran/lang.exp |   40 +++++++++++++++++++++++++++++++++++++
 2 files changed, 46 insertions(+), 2 deletions(-)

Index: gdb/symtab.c
===================================================================
--- gdb/symtab.c.orig	2007-01-27 20:35:18.000000000 -0500
+++ gdb/symtab.c	2007-01-27 20:35:34.000000000 -0500
@@ -4189,8 +4189,12 @@ find_main_name (void)
     }
 
   /* The languages above didn't identify the name of the main procedure.
-     Fallback to "main".  */
-  set_main_name ("main");
+     Fallback to "MAIN__" (g77 and gfortran) if we can find it in the 
+     minimal symtab, to "main" otherwise.  */
+  if (lookup_minimal_symbol ("MAIN__", NULL, NULL))
+    set_main_name ("MAIN__");
+  else
+    set_main_name ("main");
 }
 
 char *
Index: gdb/testsuite/gdb.fortran/lang.exp
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ gdb/testsuite/gdb.fortran/lang.exp	2007-01-27 20:35:34.000000000 -0500
@@ -0,0 +1,40 @@
+# Copyright 2005 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 this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  
+
+# This file was written by Wu Zhou. (woodzltc@cn.ibm.com)
+
+# This file is part of the gdb testsuite.  It is intended to test that gdb
+# could recognize the Fortran language after loading the binary
+
+if $tracelevel then {
+	strace $tracelevel
+}
+
+set testfile "array-element"
+set srcfile ${srcdir}/${subdir}/${testfile}.f
+set binfile ${objdir}/${subdir}/${testfile}
+
+if  { [gdb_compile "${srcfile}" "${binfile}" executable {debug f77}] != "" } {
+    untested "Couldn't compile ${srcfile}"
+    return -1
+}
+
+gdb_exit
+gdb_start
+gdb_reinitialize_dir $srcdir/$subdir
+gdb_load ${binfile}
+
+gdb_test "show language" ".*currently fortran.*" "show language(fortran)"

Re: Problems while debugging fortran

[Joel Brobecker]

> No, just "break <linenumber>". However, I tried your command and it
> worked. Why? Shouldn't the behavior be the same in both cases?

It should be the same if the "current file" is set to test.f.
It looks like it isn't. For some reason, GDB thinks that the current
file is something else. Again, perhaps a copy of your GDB session
might give a clue.

-- 
Joel

Re: Problems while debugging fortran

[Carlos Eduardo Seo]

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

Joel Brobecker wrote:
>
> What command exactly did you use to set your breakpoint?
> Did you try:
>
>         (gdb) break test.f:3
>
> ?
>
No, just "break <linenumber>". However, I tried your command and it
worked. Why? Shouldn't the behavior be the same in both cases?
>
> Perhaps it would be clearer if you could post annotated copies of
> your various GDB sessions (the ones that work, and the ones that
> don't). I think it'll be easier for us to help you.
>
Ok, I will. I'll post a message later with the output of my GDB sessions.
> Are you using a recent snapshot from CVS?
>
Yes, my GDB tree is updated every day.

Thanks and 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

iD8DBQFG8s5Fqvq7Aov/qQARAt8FAJ95eDk97ktPTPyWJkDPV+XJ/VW5hgCeJZ0i
ZNVEKDDmmQIZRcwhtU0tKxc=
=iJF4
-----END PGP SIGNATURE-----

Re: Problems while debugging fortran

[Joel Brobecker]

Carlos,

> If I try to set a breakpoint by line number, gdb displays:
> 
> 	No line xx in file "init.c"

What command exactly did you use to set your breakpoint?
Did you try:

        (gdb) break test.f:3

?

> However, it works if I set the breakpoint by function name (e.g. "break
> this"). If I run the program, then clear all breakpoints and try to set
> a breakpoint by line number, it'll work IF the line is within the scope
> of that function (i.e. if I set "break this", I can't set a breakpoint
> by line in the line "print *,i*2").

Perhaps it would be clearer if you could post annotated copies of
your various GDB sessions (the ones that work, and the ones that
don't). I think it'll be easier for us to help you.

Are you using a recent snapshot from CVS?

-- 
Joel

Problems while debugging fortran

[Carlos Eduardo Seo]

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

Hello

I'm having some trouble while debugging this code:

c-------------------
c test.f
c ------------------
program this
	i=ifunc(1)
        print *,i
end

function ifunc(i)
        print *,i*2
        ifunc = 1
        return
end
c ------------------

If I try to set a breakpoint by line number, gdb displays:

	No line xx in file "init.c"

However, it works if I set the breakpoint by function name (e.g. "break
this"). If I run the program, then clear all breakpoints and try to set
a breakpoint by line number, it'll work IF the line is within the scope
of that function (i.e. if I set "break this", I can't set a breakpoint
by line in the line "print *,i*2").

What I believe is that the psymtab does not contain either function
symbols, since it's behaving differently when the psymtab is read and
when the corresponding symtab is read in. That's why GDB cannot find the
lines (worse, it's looking for them in the wrong file).

Is that line of thought correct? Any ideas where I should start looking
for the problem?

Thanks and 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

iD8DBQFG6wNbqvq7Aov/qQARAq0OAJ0X+xgtyA7+MnPIJostKRmpY3iylACffdNc
/3EYMQfX7tINpGHt03i/Cqg=
=bvvo
-----END PGP SIGNATURE-----