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

[Daniel Berlin]

On Fri, 2006-02-24 at 16:34 -0500, Ron Brender wrote:
> There are several intermingling issues here, unfortunately.
> 
> Some languages are quite explicit about what routine is the main routine 
> of a program. A compiler can mark it so. Ada comes to mind.
> 
> Other languages are quite explit about whether any particular routine 
> can validly be a main routine. But there may be multiple such in a 
> program and the actual main routine is detemined in some other way 
> (linker option, first encounted, ?). COBOL comes to mind.
> 
> Some languages may have code that must be executed prior to the code of 
> the main program. C++ constructors come to mind? In this case is the 
> "logical" main routine of interest, or the "real" main routine (of 
> constructors) of interest? Or sometimes both?

At least in GDB's case, the functionality it used the STABS N_MAIN
"stab" for only wanted to  discover the logical main routine of interest
(for the reasons Jim described).

I'm loathe to believe we should try to come up with an all encompassing
solution when the functionality of N_MAIN (IE find the logical main
routine) is all the debugger users I've met have been clamoring for. :)

Thinking from the consumer perspective, I don't believe there is
anything useful i could provide my users that we do not already if you
also told me where the "real" main routine was.



> 
> Some environments can have "main" entry points in shared images that act 
> as main routines iff the image is activated as a "main image". 

I was afraid you would point this out.
Are these environments still around?

The last one I remember was BeOS, which is quite clearly dead :)

> Is such a 
> "conditional main routine" that same as or different than a main routine 
> as defined above, or something else?

It would probably have to fall into the category of the above.  It would
be up to the consumer to determine what the program they are running is,
and thus, what image it should be looking at to find the "logical main"
routine.

> 
> I expect that are other variations that escape me at the moment. 
> Additions to this taxonomy are certainly invited.
> 
> Useful insight might also be found by asking for examples where debugger 
> implementors are troubled by having to incorporate environment specific 
> knowledge and methods that they would rather not get involved in.


> 
> In any case, it seems clear to me that DWARF constructs, which are 
> inherently a compiler created descriptive mechanism, are at best only a 
> part of the overall descriptive problem. The question is what additional 
> DWARF information can be helpful enough to be useful often enough to be 
> worthwhile incorporating in the DWARF format.

This is where I believe the answer is clear.  I don't believe consumers
could use information *other* than something (be it attribute, tag, or
bright yellow costume) to tell them the logical main routine, often
enough that we should worry about it.

At least, nobody has requested more from ibm's compilers/debuggers, or
gcc/gdb.

--Dan