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

Michael Eager eager
Fri Feb 24 09:30:30 GMT 2006


It's probably better to move this to the DWARF Workgroup
mailing list.  The discussion list is for questions about
DWARF; the workgroup list is for DWARF development.  I'm
ccing Dwarf-discuss, but future discussion should be on the
workgroup mailing list.

I have a couple philosophical suggestions, a few questions,
and some comments about the proposal.

Suggestions:

Tags distinguish different kinds of things (e.g., DW_TAG_FISH
and DW_TAG_DOG), while attributes describe features of these
things and may be applied to different tags if appropriate (e.g.,
DW_AT_SMALL, DW_AT_WHITE, DW_AT_SHORT_TAIL, DW_AT_FINS).  If
what you want to describe is a feature or quality which
distinguishes one item of a class from another, which are
otherwise the same, then create an attribute to describe this
difference.  If you are describing something new and different,
then create a new tag.   (We haven't always followed this
principle closely, for a variety of reasons, so there are parts
of the DWARF spec where things which are very similar, like
structure and class, have different tags.)

Keep tag and attribute meanings pure and consistent,
independent of the context in which they are used.
Don't reuse a tag or attribute to mean different things.  It's
OK to expand the scope where a tag or attribute is used to
address new languages or features.

Draft proposals so that there is one recommendation on
the table.  Proposals which are "we could to this, or we
could do that, or we could do the other" are much less clear
than "this is the problem; this is the solution".   Get the
discussion out on the floor and thrashed out before drafting
a proposal.

Questions:

This proposal only mentions C, and says that it isn't needed
for this language.  (C++ and Java have no need.)  What
languages need this extension?

Is it always possible for the compiler for these languages
to identify the "main" function, or is this sometimes done
by a linker or loader?

Are there other means for identifying this information?
For example, how does the program loader know where the "main"
function is, or does it need to know?

What is done currently to address this situation?

My memory of Fortran is antediluvian, but I thought that
entry points were unrelated to which function was the "main"
function.  I thought that they were a means to combine similar
code together with two different function names, like sin() and
cos().  A "main" function in Fortran doesn't need to have
an alternate entry point.

What do Ada, Cobol, or other languages do to specify the
"main" function?

Comments about the proposal:

It seems to me that if this information is needed, then
this should be an attribute (say, DW_AT_main) which can
be used with DW_TAG_subprogram, perhaps with the restriction
that only one such attribute may be present in a program.

Repurposing DW_TAG_entry_point or DW_CC_program to mean
something different isn't a good idea.  See suggestion #2
above.

A clear statement of the problem you are trying to address
goes a long way to support your proposal.  The problem
statement here is less than clear.  Mentioning that C doesn't
need this or stabs has N_MAIN adds little to clarify this.
If the question is "what's the problem?", then creating yet
more possible solutions isn't the answer.  (Put yourself
into the position of looking at this proposal a year from
now.  It's much easier to understand if the proposal is
concise and clear, than if it requires you to remember the
circumstances when it was made or to try to infer the
problem from the proposed solution.)


Daniel Berlin wrote:
> On Thu, 2006-02-23 at 19:40 -0800, Michael Eager wrote:
> 
>>Daniel Berlin wrote:
>>
>>>On Thu, 2006-02-23 at 18:55 -0800, Michael Eager wrote:
>>>
>>>
>>>>Wu Zhou wrote:
>>>>
>>>>
>>>>>Hello, committee members
>>>>>
>>>>>Now that DWARF-3 had been published for a while, can I have the pleasure 
>>>>>to re-open this deferred issue?
>>>>>
>>>>>I don't see any action I can do from the net.  So I am asking here.
>>>>>
>>>>>Regards
>>>>>- Wu Zhou
>>>>
>>>>http://dwarf.freestandards.org/ShowIssue.php?issue=050808.2&type=closed
>>>>
>>>>We will consider revisions to the DWARF standard starting mid-year.
>>>>
>>>>The proposal is somewhat vague.  I'm personally unclear
>>>>why there is a need for an new TAG.  Saying Stabs does something
>>>>one way so DWARF should do the same is not persuasive.
>>>>
>>>>Is there a reason why using DW_TAG_entry_point doesn't work?
>>>
>>>
>>>DW_TAG_entry_point was very specifically pointed out to *not* be the
>>>same as what he is looking for, IIRC.
>>
>>As I indicated, the proposal is vague.  Also short.
>>
>>The mention of DW_TAG_entry_point along with your name suggests, in an
>>unclear fashion, that you believed it to be adequate.  Perhaps this is
>>inaccurate, but that's at least how I read the proposal.
> 
> Well, it would be, but we'd need a flag.
> 
> 
> 
> 
>>>>In general, proposals which have been implemented are preferred.
>>>
>>>We specifically put off adding it to GCC to get resolution *first*, so
>>>this is kinda a downer.  Why create the chance that someone will do this
>>>again a different way, when this is a simple issue that could be
>>>resolved once, first?
>>>
>>>This is not something we need heavy implementation experience to determine 
>>>whether it is useful or not.  
>>>But I guess for now, Wu, DW_TAG_GNU_entry_point or whatever should be added.
>>
>>Again, this is a general principle.  Unless there is a clear
>>proposal (which this is not) then the preference is for some
>>demonstration that the proposed change actually addresses
>>the issue.
>>
>>Again, I read the very few lines of the proposal and I don't
>>find it clear.  Perhaps making a clear and complete proposal
>>would be a more productive way to get a resolution.
> 
> 
> Okay, well, let me simply edit the "proposal" (which i agree is not a
> proposal)
> 
> Most C compiler assume the main function to be "main".  Other 
> languages might have different names, or even allow it to have 
> any name.  If we have an entry to tell what is the main function 
> in a program, it will let the debugger to present this to users 
> in an intelligent way.  Another debug-info format stabs could 
> support this with N_MAIN stab type.
> 
> 
> Proposal:
> 
> I propose we modify the definition of the DW_TAG_entry_point tag definition to state 
> that it is also usable for specifying the main entry point to a program, 
> not just fortran alternate entry points.
> 
> In order to determine which of the DW_TAG_entry_point is the single main entry point to the program,
>  a flag attribute DW_AT_is_main(or something suitably named) should be added to the allowed attributes for DW_TAG_entry_point.
> 
> 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."
> 
> 
> 
> 
> 


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



More information about the Dwarf-discuss mailing list