[Dwarf-discuss] DWARF Issue 050808.2&body=Re: <ahref=http://dwarf.freestandards.org/ShowIssue.php

[Daniel Berlin]

On Fri, 2006-02-24 at 11:29 -0800, Michael Eager wrote:
> Daniel Berlin wrote:
> 
> > Which is why it's already confusing what the heck DW_TAG_entry_point is
> > supposed to be used for (it probably should have been named
> > DW_TAG_alternate_entry or something).  
> 
> While there's not a lot of explanation, I think that the DWARF
> standard is explicit:  DW_TAG_entry_point is a Fortran alternate
> entry point.  Any other use for this tag does not follow the standard.
> 
> > It would be nice to have an example in the next standard for what
> > exactly it *is* used for
> > 
> > It's apparently *none* of these things (HLL starting point, actual
> > program entry point) that i've ever seen referred to as an "entry
> > point".  Fortran is probably the one language i never bothered to learn,
> > but i imagine i'm not alone.
> 
> It's a Fortran-specific feature, as the DWARF standard says.

> As Jim Blandy said, the tag is a specific mapping to a specific
> language feature and the name is based on this feature name.
> It's a "term of art" in the Fortran language.  

And is also a term of art in general compilers, linkers, loaders, and
debuggers.

I would wager a large amount of money that out of these groups of
people, 90% think of entry point as something *other than this 'fortran
term of art'*

That is why i proposed to rename it.

> The fact that you are
> not familiar with this language is not a very c
> ompelling reason forchanging it's name or giving it a different meaning.  Sorry.
Whatever Michael, this issue is a side issue anyway.

I only made it part of a formal proposal so that you would stop saying
we should implement it first, then come back and make a proposal, and
because I believe that generating discussion will lead to the right
answer (and it seems to have).
I'm sure you will respond that we don't have enough information to
generate discussion, or something of the sort.

> >>>Alternatively, we could define it as the entry_point with
> >>>DW_CC_program calling convention, and delete the text that says "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."
> >>
> >>This isn't appropriate because it would interfere with any other
> >>DW_AT_calling_convention that applied to the main routine - for
> >>instance, sh-elf-gcc with -mrenesas will mark main with
> >>DW_CC_GNU_renesas_sh.
> > 
> > 
> > I wasn't aware anyone had extended the cc attribute. There goes that
> > idea.
> 
> Extending the DW_CC attribute is entirely appropriate. 

>  If there are
> multiple ways to call a subroutine, then this attribute describes what
> ways apply to the routine.  The DWARF spec defines three generic calling
> conventions.  The spec also defines a user extension range for additional
> calling conventions.  (I hope that DW_CC_GNU_renesas_sh is in this
> user extension range.)
> 
> Calling conventions seem unrelated to the question (if I understand
> it correctly) of where the program starts.  In C/C++, the calling
> convention for main() is no different from any other function.

> If you are proposing an extension to DWARF to support some specific
> language feature (a question which I don't think has been answered)

In some cases it is a specific language feature, in other some, it's
generally a feature of the compilers and OSen to provide some sort of
name for the main function that the user has intended to be the
subroutine run when the program is started.

Some languages (like Ada) do actually allow you to explicitly specify
the name of the main function, 
However, some just allow almost anything defined properly to be a main
function.

GCJ, for example, is a java compiler generating static executables.
Java allows anything with a static main method to be run as the main
program.

To support this, gcj has a --main option that specifies which class's
main method should be run on startup.

However, the method named "main" (or whatever the ABI in question
specifies) that gcj generates, and the OS runs, is *not* the one the
user specified.  
It is a stub that does a bunch of initialization, and then calls the one
the user specified.

Unlike in C, where this is generally hidden in something like __start,
it's not hidden in GCJ generated executables, so the first thing the
user ends up debugging is some compiler generated routine that they have
no source to, instead of the routine *they specified as main*.

This was the original purpose of the N_MAIN extension in STABS, to
specify what routine the user had said main was, or the language said
main was, so that if you step into a program, you go to the method the
user expected to be run, instead of compiler generated code.