[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 15:57 -0800, Jim Blandy wrote:
> Folks, this is a collegial discussion.  Let's save sarcasm for people
> who are actually ill-intentioned; I don't think we have any such here.
> 
> This originally seemed like a straightforward problem to me, so like
> Daniel I was disappointed that there was as much discussion as there
> has been (even as I contributed to expanding the discussion).
> 
> But I think it's more subtle than we first realized:
> 
> - We have the issue of the name of the Fortran ENTRY tag; while the
> spec is clear what the tag refers to, it's also true that 'entry
> point' has different well-recognized meanings in nearby areas, so it's
> not a good name.  I don't think renaming the tag is worth it, but I
> also think DW_TAG_alternate_entry_point would have been better.

Realize that renaming the tag almost has no cost, IMHO, only the cost to
say it was renamed.

None of the *consumers* actually care about the name, only the number it
represents, so it doesn't really introduce compatibility problems.

I will finally note that it has been confusing people other than me
since at least 2003.

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

(There are a bunch of other bugs in which other people get confused
about what DW_TAG_entry_point is supposed to be for).

I'll leave this one alone now, however.


> 
> - There's the question of making sure the information is practical to
> generate.  In cases where the entry point is only chosen after most of
> the compilation is finished, it's not reasonable to expect the linker
> to go through and re-jigger the main function's CU's Dwarf info to add
> a new die or attribute.


> 
> - Ron brings up a bunch of good questions about what we really mean by
> 'entry point' anyway.

:P

> In light of all that, I think Michael's suggestion that we back off
> and explain how debuggers actually use the information is reasonable.
> 
> GDB uses the main name to decide where to end backtraces.  GDB has
> options to show the entire backtrace, including the entry point
> function provided by the system run-time files (like crt0.s), but by
> default it restricts the backtrace to the user's own code; main's is
> the bottom frame on the stack.
> 
> It used to do this simply by looking for a function named "main", but
> this doesn't work well for languages other than C and C++.  I believe
> N_MAIN was added for Java.

I believe it was actually added to *STABS* for Modula-2, way the heck
back in the day.
But GDB support was indeed added for gcj's purposes.

http://sourceware.org/ml/gdb-patches/2000-q1/msg00527.html

(Note the followup, "I looked over that patch and the basic concept
looks fine.  N_MAIN is already documented in doc/stabs.texinfo.")


> 
> GDB also uses the main name for its 'start' command, which basically
> starts the program and lets it run to the beginning of 'main'.  This
> has the same problems as the previous application: for Java, it's
> clear what you'd like the 'start' command to do, but GDB doesn't have
> enough information to dope it out on its own.
> 
> GDB uses it to select a default start position for the 'list' command,
> which lists source code: if you start up GDB and type 'list', you'll
> get the code for 'main'.  Again, in Java, it's clear what GDB ought to
> do, but it doesn't have enough information to do it.

At least, in DWARF2/3 it does not.

> 
> Some C++ implementations actually have 'main' call an internal
> function '__main', which does all the C++ constructors needed at
> startup time.  GDB uses the 'main' name to recognize these calls and
> skip over them transparently.  This seems like a questionable use, to
> me; I don't think Dwarf should go out of its way to make sure this
> works.
>