[Bug java/1427] gcj should generate N_MAIN stab or DW_AT_entry_point dwarf2 debug info

[Bug java/1427] gcj should generate N_MAIN stab or DW_AT_entry_point dwarf2 debug info

[aph at gcc dot gnu dot org]

------- Additional Comments From aph at gcc dot gnu dot org  2005-08-08 11:28 -------
This bug seems to be moribund.

There exists code in gcc (gen_entry_point_die) to do this, but it is ifdef'd out
at the present time.  We could uncomment it and call it; I don't imagine it
would be hard.

Anthony, do you think this bug should be fixed?  What is the status of your gdb
patch?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2005-05-04 02:22:04         |2005-08-08 11:28:30
               date|                            |


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

[Bug java/1427] gcj should generate N_MAIN stab or DW_AT_entry_point dwarf2 debug info

[green at redhat dot com]

------- Additional Comments From green at redhat dot com  2005-08-08 15:14 -------
(In reply to comment #9)
> Anthony, do you think this bug should be fixed? 

Yes, I think so.

> What is the status of your gdb
> patch?

It hasn't been applied.  I never followed up on the comments from the gdb
maintainers.  I can do that if it looks like gcj or jvgenmain will be fixed.

AG

-- 


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

[Bug java/1427] gcj should generate N_MAIN stab or DW_AT_entry_point dwarf2 debug info

[aph at gcc dot gnu dot org]

------- Additional Comments From aph at gcc dot gnu dot org  2005-08-08 15:23 -------
I think we have deadlock here!  It's easy enough to fix this once the changes
have been made to gdb but pretty pointless otherwise.

-- 


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

[Bug java/1427] gcj should generate N_MAIN stab or DW_AT_entry_point dwarf2 debug info

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-08-08 15:45 -------
(In reply to comment #11)
> I think we have deadlock here!  It's easy enough to fix this once the changes
> have been made to gdb but pretty pointless otherwise.

Note: the gdb changes are also needed for fortran, see PR 23280.

-- 


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

[Bug java/1427] gcj should generate N_MAIN stab or DW_AT_entry_point dwarf2 debug info

[drow at false dot org]

------- Additional Comments From drow at false dot org  2005-08-08 15:48 -------
Subject: Re:  gcj should generate N_MAIN  stab or DW_AT_entry_point dwarf2 debug info

On Mon, Aug 08, 2005 at 03:23:22PM -0000, aph at gcc dot gnu dot org wrote:
> I think we have deadlock here!  It's easy enough to fix this once the changes
> have been made to gdb but pretty pointless otherwise.

I don't think there's any deadlock: it's easy to fix either without the
other, just no one's had time or interest to fix either.



-- 


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

[Bug java/1427] gcj should generate N_MAIN stab or DW_AT_entry_point dwarf2 debug info

[woodzltc at sources dot redhat dot com]

------- Additional Comments From woodzltc at sources dot redhat dot com  2005-08-09 04:11 -------
OK. I had some time and would like to have a look into this, and I found 
something inconsistent. My founding is listed below, wishing that it can help 
clarify the situation a little:  
 
1. Someone mentioned DW_AT_entry_point in above comments. It should be a typo 
IMHO.  In DWARF standard, there is no such an attribute named 
DW_AT_entry_point, but there does exist a tag named DW_TAG_entry_point. 
 
2. Seen from the DWARF standard, DW_TAG_entry_point doesn't live to act as 
what was supposed to do.  Section-3.3 of DWARF-3 standard (Subroutine and 
Entry Point Entries) says: 
 
DW_TAG_entry_point	A Fortran alternate entry point 
 
Although I am not very sure about what it means by "alternate entry point".  
But I believe that it is not to represent the entry point in the final 
executable.  
 
3. I had a browsing over the DWARF standard, didn't found anything that is the 
same as N_MAIN in stabs.  Maybe we can suggest DWARF to add such a tag?  Any 
comments? 
 
Regards 
- Wu Zhou 

-- 


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

[Bug java/1427] gcj should generate N_MAIN stab or DW_AT_entry_point dwarf2 debug info

[dberlin at dberlin dot org]

------- Additional Comments From dberlin at gcc dot gnu dot org  2005-08-09 04:18 -------
Subject: Re:  gcj should generate N_MAIN  stab or
	DW_AT_entry_point dwarf2 debug info

On Tue, 2005-08-09 at 04:11 +0000, woodzltc at sources dot redhat dot
com wrote:
> ------- Additional Comments From woodzltc at sources dot redhat dot com  2005-08-09 04:11 -------
> OK. I had some time and would like to have a look into this, and I found 
> something inconsistent. My founding is listed below, wishing that it can help 
> clarify the situation a little:  
>  
> 1. Someone mentioned DW_AT_entry_point in above comments. It should be a typo 
> IMHO.  In DWARF standard, there is no such an attribute named 
> DW_AT_entry_point, but there does exist a tag named DW_TAG_entry_point. 
>  
> 2. Seen from the DWARF standard, DW_TAG_entry_point doesn't live to act as 
> what was supposed to do.  Section-3.3 of DWARF-3 standard (Subroutine and 
> Entry Point Entries) says: 

DWARF3 is not quite standardized yet.
But it's weeks away.

>  
> DW_TAG_entry_point	A Fortran alternate entry point 

Yes, well, i can bring it up if you want, but it seems the right way to
describe your entry points.

>  
> Although I am not very sure about what it means by "alternate entry point".  
> But I believe that it is not to represent the entry point in the final 
> executable.  

This is wrong, at least for fortran.

>  
> 3. I had a browsing over the DWARF standard, didn't found anything that is the 
> same as N_MAIN in stabs.  Maybe we can suggest DWARF to add such a tag?  Any 
> comments? 
>  

Please add an issue on dwarf.freestandards.org and i'll take it from
there.

> Regards 
> - Wu Zhou 
> 



-- 


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

[Bug java/1427] gcj should generate N_MAIN stab or DW_AT_entry_point dwarf2 debug info

[woodzltc at sources dot redhat dot com]

------- Additional Comments From woodzltc at sources dot redhat dot com  2005-08-09 07:04 -------
(In reply to comment #15)

[snip]

> Please add an issue on dwarf.freestandards.org and i'll take it from
> there.
 
I had added an public comment titiled "add a new entry to identify the main
function in a program", but it didn't return me an issue number.  Maybe it is
due to the fact that I didn't fill section number and page info. (the reason is
that I don't know which section if apply to).  Do I need to fill all the fields?  

If you can't see that, I will try again with a bogus section and page.

-- 


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

[Bug java/1427] gcj should generate N_MAIN stab or DW_AT_entry_point dwarf2 debug info

[woodzltc at sources dot redhat dot com]

------- Additional Comments From woodzltc at sources dot redhat dot com  2005-08-24 06:06 -------
I just found the above issue I opened is defered to DWARF4. (Pls refer to 
http://dwarf.freestandards.org/ShowIssue.php?issue=050808.2&type=closed).  Did 
it means that we need to wait a long time to have this accepted/reviewed?  
 
Another oddity I noticed is that I didn't get any notification when the status 
of the above issue got changed.  I opened this issue anyway. And I had also 
provided my email when opening it. :-)  
 
Anyone who knows how to get myself notified when the status of a specific 
issue gets changed.  TIA.  

-- 


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

[Bug java/1427] gcj should generate N_MAIN stab or DW_AT_entry_point dwarf2 debug info

[woodzltc at sources dot redhat dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1866 bytes --]



------- Comment #18 from woodzltc at sources dot redhat dot com  2005-11-15 03:04 -------
Hi Andrew,

(In reply to comment #8)
> Dwarf2 has DW_AT_entry_point for the same thing as the stabs N_MAIN.

I am now believing that DW_CC_program is for this purpose in DWARF.  Please
have a look at the following two excerpted paragraphs in section 3.3.1 of DWARF
standard:

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.

==== End of the excerpt ====

Although it is intended to support Fortran main programs.  But I think that it
might also be ok for java as well.

If my understanding is right, I think the fix is not that hard (at least for
gfortran).  Here is my thought: when gfortran trying to emit symbol MAIN__, we
can add an extra attribute DW_AT_calling_convention and set it to
DW_CC_program.  Then in gdb's dwarf2reader, we can add a routine to find out
the symbol whose DW_AT_calling_convention is DW_CC_program, and set it to the
main function.  

I am not familar with the gfortran code, if anyone could code the above patch
in gfortran's side, I could try to code in the gdb's side.  But if anyone is
willing to point out where to emit DWARF debuginfo for MAIN__ in gfortran's
source, I am very happy to have a try in gfortran.

For java, the process might be the same.


-- 


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

[Bug java/1427] gcj should generate N_MAIN stab or DW_AT_entry_point dwarf2 debug info

[steven at gcc dot gnu dot org]

------- Comment #19 from steven at gcc dot gnu dot org  2006-10-14 14:17 -------
Someone should make gdb understand the DW_AT_calling_convention attribute. 
This is the bit necessary to make it work for Fortran.  I considered stealing a
bit on FUNCTION_DECL to mark it as the main program but it seems to me that
this hard-coded solution should be acceptable as well (but, your thoughts?).


Index: dwarf2out.c
===================================================================
--- dwarf2out.c (revision 117672)
+++ dwarf2out.c (working copy)
@@ -11105,11 +11105,18 @@ add_calling_convention_attribute (dw_die
 {
   enum dwarf_calling_convention value = DW_CC_normal;

-  value = targetm.dwarf_calling_convention (type);
+  if (is_fortran ())
+    {
+      /* The subroutine named MAIN__ is the main program for Fortran.  */
+      const char *subroutine_name = get_AT_string (subr_die, DW_AT_name);
+      if (strcmp (subroutine_name, "MAIN__") == 0)
+       value = DW_CC_program;
+    }
+  else
+    value = targetm.dwarf_calling_convention (type);

-  /* Only add the attribute if the backend requests it, and
-     is not DW_CC_normal.  */
-  if (value && (value != DW_CC_normal))
+  /* Only add the attribute if it is not DW_CC_normal.  */
+  if (value != DW_CC_normal)
     add_AT_unsigned (subr_die, DW_AT_calling_convention, value);
 }


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |steven at gcc dot gnu dot
                   |                            |org


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