User account creation filtered due to spam.

Bug 1427 - gcc should allow gcj and gfortran to generate N_MAIN stab or DW_AT_entry_point dwarf2 debug info
Summary: gcc should allow gcj and gfortran to generate N_MAIN stab or DW_AT_entry_poi...
Status: RESOLVED WONTFIX
Alias: None
Product: gcc
Classification: Unclassified
Component: java (show other bugs)
Version: 2.97
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 11443 (view as bug list)
Depends on:
Blocks:
 
Reported: 2000-12-20 12:19 UTC by Tom Tromey
Modified: 2016-09-30 22:51 UTC (History)
9 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2006-02-13 04:09:55


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Anthony Green 2000-03-05 09:39:50 UTC
State-Changed-From-To: open->analyzed
State-Changed-Why: I've submitted a patch for the GDB side of things.
    http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00527.html
    
    On the gcj side, all we really need to do is hack jvgenmain
    to emit:
    asm ( ".stabs \"myClass.main\", 0x2a, 0, 0, 0 " );
    ...at the top of the "main" source file.
    
    We should probably only do this on stabs systems.
    
    We will have to invent a DWARF2 way of doing this.  I
    don't think DWARF2 has anything like N_MAIN yet.
Comment 1 Anthony Green 2000-03-05 17:39:50 UTC
From: green@cygnus.com
To: apbianco@cygnus.com, java-gnats@sourceware.cygnus.com, jimb@cygnus.com,
  tromey@cygnus.com
Cc:  
Subject: Re: gcj/49
Date: 5 Mar 2000 17:39:50 -0000

 Synopsis: gcj should generate N_MAIN stab
 
 State-Changed-From-To: open->analyzed
 State-Changed-By: green
 State-Changed-When: Sun Mar  5 09:39:50 2000
 State-Changed-Why:
     I've submitted a patch for the GDB side of things.
     http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00527.html
     
     On the gcj side, all we really need to do is hack jvgenmain
     to emit:
     asm ( ".stabs \"myClass.main\", 0x2a, 0, 0, 0 " );
     ...at the top of the "main" source file.
     
     We should probably only do this on stabs systems.
     
     We will have to invent a DWARF2 way of doing this.  I
     don't think DWARF2 has anything like N_MAIN yet.
 
 http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&pr=49&database=java

Comment 2 Anthony Green 2000-04-23 09:52:00 UTC
From: Anthony Green <green@cygnus.com>
To: java-gnats@sourceware.cygnus.com, jimb@cygnus.com, apbianco@cygnus.com,
        tromey@cygnus.com
Cc:  
Subject: Re: gcj/49
Date: Sun, 23 Apr 2000 09:52:00 -0700

 I don't have a full patch for this yet. but this is very close.  All
 that's missing is a check to see whether or not we should actually
 emit it.  I think the compiler driver should pass this info down to
 jvgenmain.  Do any of you understand specs will enough to do this?
 
 Index: gcc/java/jvgenmain.c
 ===================================================================
 RCS file: /cvs/gcc/egcs/gcc/java/jvgenmain.c,v
 retrieving revision 1.15
 diff -c -r1.15 jvgenmain.c
 *** jvgenmain.c 2000/01/21 20:57:00 1.15
 --- jvgenmain.c 2000/04/23 16:45:03
 ***************
 *** 155,160 ****
 --- 155,165 ----
       }
     fprintf (stream, "  0\n};\n\n");
 
 +   /* Emit the N_MAIN stab.  */
 +   fprintf (stream, "asm ( \"/* Emit the N_MAIN stab identifying the
 program's `main'\n");
 +   fprintf (stream, "asm ( \".stabs \\\"%s.main\\\", 0x2a, 0, 0, 0 \"
 );\n\n",
 +     classname);
 +
     fprintf (stream, "extern struct Class %s%s;\n",
       class_mangling_prefix, mangled_classname);
     fprintf (stream, "int main (int argc, const char **argv)\n");
 
 
 http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&pr=49&database=java

Comment 3 Tom Tromey 2000-04-23 09:58:31 UTC
From: Tom Tromey <tromey@cygnus.com>
To: green@cygnus.com
Cc: java-gnats@sourceware.cygnus.com, jimb@cygnus.com, apbianco@cygnus.com,
        tromey@cygnus.com
Subject: Re: gcj/49
Date: Sun, 23 Apr 2000 09:58:31 -0700 (PDT)

 Anthony> I don't have a full patch for this yet. but this is very
 Anthony> close.  All that's missing is a check to see whether or not
 Anthony> we should actually emit it.  I think the compiler driver
 Anthony> should pass this info down to jvgenmain.  Do any of you
 Anthony> understand specs will enough to do this?
 
 I could figure it out if I knew how to determine whether we need to
 emit this.  For instance, how do I know when the platform does not
 support stabs?  And how do I know whether or not it is needed?  Do I
 just check for -g?  (And how are we going to make this work with
 Dwarf?)
 
 Tom

Comment 4 Anthony Green 2000-04-23 10:09:14 UTC
From: Anthony Green <green@cygnus.com>
To: tromey@cygnus.com
Cc: java-gnats@sourceware.cygnus.com, jimb@cygnus.com, apbianco@cygnus.com,
        tromey@cygnus.com
Subject: Re: gcj/49
Date: Sun, 23 Apr 2000 10:09:14 -0700

 Tom wrote:
 > I could figure it out if I knew how to determine whether we need to
 > emit this.
 
 I think we only want to do it when `write_symbols == DBX_DEBUG' in
 toplev.c.  This probably doesn't help because we need to know in
 gcc.c.
 
 Jim - can gdb handle programs with both DWARF2 and STABS?  I think
 maybe it can.  
 
 In that case, maybe we just always emit it when any `-g' flag appears
 on the command line.
 
 > (And how are we going to make this work with Dwarf?)
 
 There's not dwarf way of doing it.  I think mixed stabs/dwarf will
 work for now.
 
 AG
 
 -- 
 Anthony Green                                                        Red Hat
                                                        Sunnyvale, California

Comment 5 Jim Blandy 2000-04-27 17:37:21 UTC
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: green@cygnus.com
Cc: tromey@cygnus.com, java-gnats@sourceware.cygnus.com, apbianco@cygnus.com
Subject: Re: gcj/49
Date: 27 Apr 2000 17:37:21 -0500

 > Jim - can gdb handle programs with both DWARF2 and STABS?  I think
 > maybe it can.  
 
 Yes, it can.
 
 > In that case, maybe we just always emit it when any `-g' flag appears
 > on the command line.
 
 Hmm.  Can every assembler handle the .stab pseudo-ops?
Comment 6 Tom Tromey 2000-12-20 12:19:44 UTC
gcj should generate an N_MAIN stab which names
the "real" main function.  This will let gdb
present this to the user in an intelligent way,
so that users won't see the jvgenmain-generated
main() but will instead start the debug session
in their own code.

Release:
current cvs
Comment 7 Andrew Pinski 2003-08-03 20:14:37 UTC
*** Bug 11443 has been marked as a duplicate of this bug. ***
Comment 8 Andrew Pinski 2003-08-03 20:16:23 UTC
Dwarf2 has DW_AT_entry_point for the same thing as the stabs N_MAIN.
Comment 9 Andrew Haley 2005-08-08 11:28:30 UTC
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?
Comment 10 Anthony Green 2005-08-08 15:14:12 UTC
(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
Comment 11 Andrew Haley 2005-08-08 15:23:20 UTC
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.
Comment 12 Andrew Pinski 2005-08-08 15:45:01 UTC
(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.
Comment 13 Daniel Jacobowitz 2005-08-08 15:48:35 UTC
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.

Comment 14 Wu Zhou 2005-08-09 04:11:04 UTC
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 
Comment 15 Daniel Berlin 2005-08-09 04:18:48 UTC
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 
> 

Comment 16 Wu Zhou 2005-08-09 07:04:18 UTC
(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.
Comment 17 Wu Zhou 2005-08-24 06:06:38 UTC
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.  
Comment 18 Wu Zhou 2005-11-15 03:04:41 UTC
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.
Comment 19 Steven Bosscher 2006-10-14 14:17:30 UTC
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);
 }

Comment 20 Daniel Jacobowitz 2006-10-17 02:40:21 UTC
Subject: Re:  gcj should generate N_MAIN  stab or DW_AT_entry_point dwarf2 debug info

On Sat, Oct 14, 2006 at 02:17:32PM -0000, steven at gcc dot gnu dot org wrote:
> 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?).

I don't remember the discussion entirely, and can't find it now, but I
thought that the conclusion was that DW_AT_calling_convention was not
appropriate for this purpose?  In gfortran, main-ness doesn't affect
whether the function can be called or not, or how to call it, I don't
think.

Compare to DW_CC_GNU_renesas_sh, indicating a different ABI.  A flag
for i386 regparm could also go here.

I guess the language in the standard allows this usage, but it would
make it impossible to mark a main routine as obeying a particular ABI.

Ah, here:
http://dwarf.freestandards.org/ShowIssue.php?issue=050808.2&type=closed

Maybe someone out to poke the committee again.

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

Probably ought to call the target hook in the fortran case
eventually...

Comment 21 Andrew Pinski 2016-09-30 22:51:13 UTC
Closing as won't fix as the Java front-end has been removed from the trunk.