[PATCH] DW_AT_calling_convention support

[PATCH] DW_AT_calling_convention support

[Petr Sorfa]

[-- Attachment #1: Type: text/plain, Size: 1175 bytes --]

Hi,

Patch for supporting DW_AT_calling_convention. This helps GDB identify
the "main" program for languages that do not have a starting subroutine
called "main". The patch also adds a new type flag,
TYPE_FLAG_MAIN_PROGRAM which is set if the type is describing a "main"
entry point. This can be used, for example, in noting a subroutine type
as a FORTRAN PROGRAM.

2002-07-09 Petr Sorfa (petrs@caldera.com)

        *  dwarf2read.c (read_subroutine_type): Expanded to recognize
           the DW_AT_calling_convention DWARF attribute and for
           DW_CC_program set the TYPE_FLAG_MAIN_PROGRAM type flag
           and call set_main_name ().
           (read_partial_die): Now recognizes the
           DW_AT_calling_convention attribute and calls set_main_name().
           Note that TYPE_FLAG_MAIN_PROGRAM type flag is not set, as
           the partial_die might not denote a subroutine type.

        *  gdbtypes.h (TYPE_FLAG_MAIN_PROGRAM): New type flag which
           indicates whether the type denotes a main program subroutine.
           (TYPE_MAIN_PROGRAM): New macro that returns a non-zero value
           if the type describes a main program subroutine.

[-- Attachment #2: calling_convention.patch --]
[-- Type: text/plain, Size: 3308 bytes --]

Index: dwarf2read.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2read.c,v
retrieving revision 1.60
diff -c -p -r1.60 dwarf2read.c
*** dwarf2read.c	22 Jun 2002 00:05:59 -0000	1.60
--- dwarf2read.c	9 Jul 2002 20:42:35 -0000
*************** read_subroutine_type (struct die_info *d
*** 3026,3031 ****
--- 3026,3053 ----
        || cu_language == language_cplus)
      TYPE_FLAGS (ftype) |= TYPE_FLAG_PROTOTYPED;
  
+   /* Check for the calling convention. A DW_CC_program indicates that
+      the subroutine is the the "main" of the program. This needs
+      to be set for languages that don't have a predefined name
+      for the starting subroutines, such as FORTRAN. */
+   attr = dwarf_attr (die, DW_AT_calling_convention);
+   if (attr && (DW_UNSND (attr) != 0))
+     {
+       switch (DW_UNSND (attr))
+         {
+           case DW_CC_program:
+             /* Set this subroutine as the "main" subroutine
+                for the program. */
+             TYPE_FLAGS (ftype) |= TYPE_FLAG_MAIN_PROGRAM;
+             set_main_name (TYPE_NAME (ftype));
+             break;
+           case DW_CC_normal:
+           case DW_CC_nocall:
+           default:
+             break;
+         }
+     }
+ 
    if (die->has_children)
      {
        struct die_info *child_die;
*************** read_partial_die (struct partial_die_inf
*** 3414,3419 ****
--- 3436,3442 ----
    int found_spec_attr = 0;
    int has_low_pc_attr = 0;
    int has_high_pc_attr = 0;
+   int is_main_program = 0;
  
    *part_die = zeroed_partial_die;
    abbrev_number = read_unsigned_leb128 (abfd, info_ptr, &bytes_read);
*************** read_partial_die (struct partial_die_inf
*** 3446,3451 ****
--- 3469,3486 ----
  	  if (part_die->name == NULL)
  	    part_die->name = DW_STRING (&attr);
  	  break;
+         case DW_AT_calling_convention:
+           switch (DW_UNSND (&attr))
+             {
+             case DW_CC_program:
+               is_main_program = 1;
+               break;
+             case DW_CC_normal:
+             case DW_CC_nocall:
+             default:
+               break;
+             }
+           break;
  	case DW_AT_MIPS_linkage_name:
  	  part_die->name = DW_STRING (&attr);
  	  break;
*************** read_partial_die (struct partial_die_inf
*** 3489,3494 ****
--- 3524,3534 ----
  	default:
  	  break;
  	}
+     }
+ 
+   if (is_main_program)
+     {
+       set_main_name (part_die->name);
      }
  
    /* If we found a reference attribute and the die has no name, try
Index: gdbtypes.h
===================================================================
RCS file: /cvs/src/src/gdb/gdbtypes.h,v
retrieving revision 1.33
diff -c -p -r1.33 gdbtypes.h
*** gdbtypes.h	14 Jun 2002 14:34:24 -0000	1.33
--- gdbtypes.h	9 Jul 2002 20:42:35 -0000
*************** enum type_code
*** 252,257 ****
--- 252,263 ----
  #define TYPE_FLAG_VECTOR	(1 << 12)
  #define TYPE_VECTOR(t)		(TYPE_FLAGS (t) & TYPE_FLAG_VECTOR)
  
+ /* This flag is to indicate that the subprogram type indicates
+    a the main program. Mainly used to indicate FORTRAN program
+    scopes. */
+ #define TYPE_FLAG_MAIN_PROGRAM	(1 << 13)
+ #define TYPE_MAIN_PROGRAM(t)	(TYPE_FLAGS (t) & TYPE_FLAG_MAIN_PROGRAM)
+ 
  struct main_type
  {
    /* Code for kind of type */

Re: [PATCH] DW_AT_calling_convention support

[Daniel Jacobowitz]

On Tue, Jul 09, 2002 at 05:20:05PM -0400, Petr Sorfa wrote:
> Hi,
> 
> Patch for supporting DW_AT_calling_convention. This helps GDB identify
> the "main" program for languages that do not have a starting subroutine
> called "main". The patch also adds a new type flag,
> TYPE_FLAG_MAIN_PROGRAM which is set if the type is describing a "main"
> entry point. This can be used, for example, in noting a subroutine type
> as a FORTRAN PROGRAM.
> 
> 2002-07-09 Petr Sorfa (petrs@caldera.com)
> 
>         *  dwarf2read.c (read_subroutine_type): Expanded to recognize
>            the DW_AT_calling_convention DWARF attribute and for
>            DW_CC_program set the TYPE_FLAG_MAIN_PROGRAM type flag
>            and call set_main_name ().
>            (read_partial_die): Now recognizes the
>            DW_AT_calling_convention attribute and calls set_main_name().
>            Note that TYPE_FLAG_MAIN_PROGRAM type flag is not set, as
>            the partial_die might not denote a subroutine type.
> 
>         *  gdbtypes.h (TYPE_FLAG_MAIN_PROGRAM): New type flag which
>            indicates whether the type denotes a main program subroutine.
>            (TYPE_MAIN_PROGRAM): New macro that returns a non-zero value
>            if the type describes a main program subroutine.

Why is the type flag necessary?  It seems wasteful to allocate a bit in
every type when there will presumably only be one such routine.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [PATCH] DW_AT_calling_convention support

[Petr Sorfa]

Hi Daniel,

Valid point, however there is a (hopefully not misguided) reason; I use
it when printing a subroutine type for FORTRAN95. I make the assumption
that determining whether a symbol name is equivalent to main_name() is
not sufficient.

Petr
> > Patch for supporting DW_AT_calling_convention. This helps GDB identify
> > the "main" program for languages that do not have a starting subroutine
> > called "main". The patch also adds a new type flag,
> > TYPE_FLAG_MAIN_PROGRAM which is set if the type is describing a "main"
> > entry point. This can be used, for example, in noting a subroutine type
> > as a FORTRAN PROGRAM.
> >
> > 2002-07-09 Petr Sorfa (petrs@caldera.com)
> >
> >         *  dwarf2read.c (read_subroutine_type): Expanded to recognize
> >            the DW_AT_calling_convention DWARF attribute and for
> >            DW_CC_program set the TYPE_FLAG_MAIN_PROGRAM type flag
> >            and call set_main_name ().
> >            (read_partial_die): Now recognizes the
> >            DW_AT_calling_convention attribute and calls set_main_name().
> >            Note that TYPE_FLAG_MAIN_PROGRAM type flag is not set, as
> >            the partial_die might not denote a subroutine type.
> >
> >         *  gdbtypes.h (TYPE_FLAG_MAIN_PROGRAM): New type flag which
> >            indicates whether the type denotes a main program subroutine.
> >            (TYPE_MAIN_PROGRAM): New macro that returns a non-zero value
> >            if the type describes a main program subroutine.
> 
> Why is the type flag necessary?  It seems wasteful to allocate a bit in
> every type when there will presumably only be one such routine.
> 
> --
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer

Re: [PATCH] DW_AT_calling_convention support

[Daniel Jacobowitz]

I'd rather save a pointer the symbol for the main function, or
something along those lines - do you think that's workable?

On Tue, Jul 09, 2002 at 05:36:46PM -0400, Petr Sorfa wrote:
> Hi Daniel,
> 
> Valid point, however there is a (hopefully not misguided) reason; I use
> it when printing a subroutine type for FORTRAN95. I make the assumption
> that determining whether a symbol name is equivalent to main_name() is
> not sufficient.
> 
> Petr
> > > Patch for supporting DW_AT_calling_convention. This helps GDB identify
> > > the "main" program for languages that do not have a starting subroutine
> > > called "main". The patch also adds a new type flag,
> > > TYPE_FLAG_MAIN_PROGRAM which is set if the type is describing a "main"
> > > entry point. This can be used, for example, in noting a subroutine type
> > > as a FORTRAN PROGRAM.
> > >
> > > 2002-07-09 Petr Sorfa (petrs@caldera.com)
> > >
> > >         *  dwarf2read.c (read_subroutine_type): Expanded to recognize
> > >            the DW_AT_calling_convention DWARF attribute and for
> > >            DW_CC_program set the TYPE_FLAG_MAIN_PROGRAM type flag
> > >            and call set_main_name ().
> > >            (read_partial_die): Now recognizes the
> > >            DW_AT_calling_convention attribute and calls set_main_name().
> > >            Note that TYPE_FLAG_MAIN_PROGRAM type flag is not set, as
> > >            the partial_die might not denote a subroutine type.
> > >
> > >         *  gdbtypes.h (TYPE_FLAG_MAIN_PROGRAM): New type flag which
> > >            indicates whether the type denotes a main program subroutine.
> > >            (TYPE_MAIN_PROGRAM): New macro that returns a non-zero value
> > >            if the type describes a main program subroutine.
> > 
> > Why is the type flag necessary?  It seems wasteful to allocate a bit in
> > every type when there will presumably only be one such routine.
> > 
> > --
> > Daniel Jacobowitz                           Carnegie Mellon University
> > MontaVista Software                         Debian GNU/Linux Developer
> 
> 

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [PATCH] DW_AT_calling_convention support

[Petr Sorfa]

Hi Daniel,

> I'd rather save a pointer the symbol for the main function, or
> something along those lines - do you think that's workable?
Sounds good. Note that I'm making the assumption that the symbol is
associated with a type that is only associated with that symbol (iff).

I think it should be API driven, like set_main_symbol () and
get_main_symbol () and situated in symtab.c alonside set_main_name() and
main_name().

Petr
> 
> On Tue, Jul 09, 2002 at 05:36:46PM -0400, Petr Sorfa wrote:
> > Hi Daniel,
> >
> > Valid point, however there is a (hopefully not misguided) reason; I use
> > it when printing a subroutine type for FORTRAN95. I make the assumption
> > that determining whether a symbol name is equivalent to main_name() is
> > not sufficient.
> >
> > Petr
> > > > Patch for supporting DW_AT_calling_convention. This helps GDB identify
> > > > the "main" program for languages that do not have a starting subroutine
> > > > called "main". The patch also adds a new type flag,
> > > > TYPE_FLAG_MAIN_PROGRAM which is set if the type is describing a "main"
> > > > entry point. This can be used, for example, in noting a subroutine type
> > > > as a FORTRAN PROGRAM.
> > > >
> > > > 2002-07-09 Petr Sorfa (petrs@caldera.com)
> > > >
> > > >         *  dwarf2read.c (read_subroutine_type): Expanded to recognize
> > > >            the DW_AT_calling_convention DWARF attribute and for
> > > >            DW_CC_program set the TYPE_FLAG_MAIN_PROGRAM type flag
> > > >            and call set_main_name ().
> > > >            (read_partial_die): Now recognizes the
> > > >            DW_AT_calling_convention attribute and calls set_main_name().
> > > >            Note that TYPE_FLAG_MAIN_PROGRAM type flag is not set, as
> > > >            the partial_die might not denote a subroutine type.
> > > >
> > > >         *  gdbtypes.h (TYPE_FLAG_MAIN_PROGRAM): New type flag which
> > > >            indicates whether the type denotes a main program subroutine.
> > > >            (TYPE_MAIN_PROGRAM): New macro that returns a non-zero value
> > > >            if the type describes a main program subroutine.
> > >
> > > Why is the type flag necessary?  It seems wasteful to allocate a bit in
> > > every type when there will presumably only be one such routine.
> > >
> > > --
> > > Daniel Jacobowitz                           Carnegie Mellon University
> > > MontaVista Software                         Debian GNU/Linux Developer
> >
> >
> 
> --
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer

Re: [PATCH] DW_AT_calling_convention support

[Daniel Jacobowitz]

On Wed, Jul 10, 2002 at 09:53:35AM -0400, Petr Sorfa wrote:
> Hi Daniel,
> 
> > I'd rather save a pointer the symbol for the main function, or
> > something along those lines - do you think that's workable?
> Sounds good. Note that I'm making the assumption that the symbol is
> associated with a type that is only associated with that symbol (iff).
> 
> I think it should be API driven, like set_main_symbol () and
> get_main_symbol () and situated in symtab.c alonside set_main_name() and
> main_name().

Yep, that's about what I had in mind.  How about:

  set_main_name ()
  set_main_symbol ()
  is_main_symbol ()
    - if a main symbol is set, check if it is the same symbol
    - otherwise, check if it has the same name as passed to
      set_main_name

(with appropriate care for when we change object files.... to one
without a DWARF-2 main symbol, even...)

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [PATCH] DW_AT_calling_convention support

[Petr Sorfa]

Hi Daniel,

Great, however I do suggest get_main_symbol() for greater flexibility.
I've moved the code to deal with DW_AT_calling_convention into
dwarf2read.c's new_symbol() function (as opposed to detecting it while
reading a type). Let me know what you think and I'll have a patch ready
soon.

Petr
> On Wed, Jul 10, 2002 at 09:53:35AM -0400, Petr Sorfa wrote:
> > Hi Daniel,
> >
> > > I'd rather save a pointer the symbol for the main function, or
> > > something along those lines - do you think that's workable?
> > Sounds good. Note that I'm making the assumption that the symbol is
> > associated with a type that is only associated with that symbol (iff).
> >
> > I think it should be API driven, like set_main_symbol () and
> > get_main_symbol () and situated in symtab.c alonside set_main_name() and
> > main_name().
> 
> Yep, that's about what I had in mind.  How about:
> 
>   set_main_name ()
>   set_main_symbol ()
>   is_main_symbol ()
>     - if a main symbol is set, check if it is the same symbol
>     - otherwise, check if it has the same name as passed to
>       set_main_name
> 
> (with appropriate care for when we change object files.... to one
> without a DWARF-2 main symbol, even...)
> 
> --
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer

Re: [PATCH] DW_AT_calling_convention support

[Daniel Jacobowitz]

[I can't approve this but] that sounds good to me.  I'm not arguing
that there shouldn't be a get_main_symbol, only that there should be
an opaque check for the main symbol which doesn't require calling both
that and get_main_name ().


On Wed, Jul 10, 2002 at 10:32:07AM -0400, Petr Sorfa wrote:
> Hi Daniel,
> 
> Great, however I do suggest get_main_symbol() for greater flexibility.
> I've moved the code to deal with DW_AT_calling_convention into
> dwarf2read.c's new_symbol() function (as opposed to detecting it while
> reading a type). Let me know what you think and I'll have a patch ready
> soon.
> 
> Petr
> > On Wed, Jul 10, 2002 at 09:53:35AM -0400, Petr Sorfa wrote:
> > > Hi Daniel,
> > >
> > > > I'd rather save a pointer the symbol for the main function, or
> > > > something along those lines - do you think that's workable?
> > > Sounds good. Note that I'm making the assumption that the symbol is
> > > associated with a type that is only associated with that symbol (iff).
> > >
> > > I think it should be API driven, like set_main_symbol () and
> > > get_main_symbol () and situated in symtab.c alonside set_main_name() and
> > > main_name().
> > 
> > Yep, that's about what I had in mind.  How about:
> > 
> >   set_main_name ()
> >   set_main_symbol ()
> >   is_main_symbol ()
> >     - if a main symbol is set, check if it is the same symbol
> >     - otherwise, check if it has the same name as passed to
> >       set_main_name
> > 
> > (with appropriate care for when we change object files.... to one
> > without a DWARF-2 main symbol, even...)
> > 
> > --
> > Daniel Jacobowitz                           Carnegie Mellon University
> > MontaVista Software                         Debian GNU/Linux Developer
> 
> 

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [PATCH] DW_AT_calling_convention support

[Jim Blandy]

Sorry, so what's the final proposal at this point?

Re: [PATCH] DW_AT_calling_convention support

[Petr Sorfa]

Hi Jim,

> Sorry, so what's the final proposal at this point?
Implement set_main_symbol(), get_main_symbol(), is_main_symbol() and
adjust the DWARF code accordingly. I've basically already done this and
I'm doing testing currently.

Petr

Re: [PATCH] DW_AT_calling_convention support

[Petr Sorfa]

Hi Jim,

Ok, during testing I realized that I have to detect DW_AT_calling before
symbol creation while reading in dies and types (I had this in the
original patch, but removed it thinking it was redundant.) The main
reason is to call set_main_name() so that the correct program language
is determined on program load before execution. set_main_symbol() is now
called within new_symbol().

Petr
> > Sorry, so what's the final proposal at this point?
> Implement set_main_symbol(), get_main_symbol(), is_main_symbol() and
> adjust the DWARF code accordingly. I've basically already done this and
> I'm doing testing currently.

Re: [PATCH] DW_AT_calling_convention support

[Jim Blandy]

Petr Sorfa <petrs@caldera.com> writes:
> Ok, during testing I realized that I have to detect DW_AT_calling before
> symbol creation while reading in dies and types (I had this in the
> original patch, but removed it thinking it was redundant.) The main
> reason is to call set_main_name() so that the correct program language
> is determined on program load before execution. set_main_symbol() is now
> called within new_symbol().

Okay, I'll look forward to the patch.

Is checking the calling convention really the approved technique for
recognizing a Fortran entry point in Dwarf 2?  Is it really the case
that Fortran programs always only have one function with this calling
convention?  Would your patch do something sensible if it found more
than one?

Re: [PATCH] DW_AT_calling_convention support

[Petr Sorfa]

Hi Jim,

> Okay, I'll look forward to the patch.
In a few minutes.

> Is checking the calling convention really the approved technique for
> recognizing a Fortran entry point in Dwarf 2?  Is it really the case
> that Fortran programs always only have one function with this calling
> convention?  Would your patch do something sensible if it found more
> than one?
Good question, the Dwarf standard V3 Draft 7 Page 44 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."

So the answer is yes and no. But I think the patch is valid as it
determines not the entry point, but the main program. As far as I am
aware you can have only one PROGRAM entry per FORTRAN program. If there
is more than one found, the patch just uses the last read entry. I don't
think supporting a more intricate way would be much use (such as keeping
a list of DW_CC_program entries.)

Petr

Re: [PATCH] DW_AT_calling_convention support

[Jim Blandy]

Petr Sorfa <petrs@caldera.com> writes:
> > Okay, I'll look forward to the patch.
> In a few minutes.
> 
> > Is checking the calling convention really the approved technique for
> > recognizing a Fortran entry point in Dwarf 2?  Is it really the case
> > that Fortran programs always only have one function with this calling
> > convention?  Would your patch do something sensible if it found more
> > than one?
> Good question, the Dwarf standard V3 Draft 7 Page 44 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."
> 
> So the answer is yes and no. But I think the patch is valid as it
> determines not the entry point, but the main program. As far as I am
> aware you can have only one PROGRAM entry per FORTRAN program. If there
> is more than one found, the patch just uses the last read entry. I don't
> think supporting a more intricate way would be much use (such as keeping
> a list of DW_CC_program entries.)

What's the difference between the entry point and the main program?

Re: [PATCH] DW_AT_calling_convention support

[Daniel Jacobowitz]

On Wed, Jul 10, 2002 at 01:40:58PM -0500, Jim Blandy wrote:
> 
> Petr Sorfa <petrs@caldera.com> writes:
> > > Okay, I'll look forward to the patch.
> > In a few minutes.
> > 
> > > Is checking the calling convention really the approved technique for
> > > recognizing a Fortran entry point in Dwarf 2?  Is it really the case
> > > that Fortran programs always only have one function with this calling
> > > convention?  Would your patch do something sensible if it found more
> > > than one?
> > Good question, the Dwarf standard V3 Draft 7 Page 44 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."
> > 
> > So the answer is yes and no. But I think the patch is valid as it
> > determines not the entry point, but the main program. As far as I am
> > aware you can have only one PROGRAM entry per FORTRAN program. If there
> > is more than one found, the patch just uses the last read entry. I don't
> > think supporting a more intricate way would be much use (such as keeping
> > a list of DW_CC_program entries.)
> 
> What's the difference between the entry point and the main program?

The entry point is an implementation detail - like _start.  The main
program is in user code, main() or "program foo".

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [PATCH] DW_AT_calling_convention support

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:
> On Wed, Jul 10, 2002 at 01:40:58PM -0500, Jim Blandy wrote:
> > 
> > Petr Sorfa <petrs@caldera.com> writes:
> > > > Okay, I'll look forward to the patch.
> > > In a few minutes.
> > > 
> > > > Is checking the calling convention really the approved technique for
> > > > recognizing a Fortran entry point in Dwarf 2?  Is it really the case
> > > > that Fortran programs always only have one function with this calling
> > > > convention?  Would your patch do something sensible if it found more
> > > > than one?
> > > Good question, the Dwarf standard V3 Draft 7 Page 44 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."
> > > 
> > > So the answer is yes and no. But I think the patch is valid as it
> > > determines not the entry point, but the main program. As far as I am
> > > aware you can have only one PROGRAM entry per FORTRAN program. If there
> > > is more than one found, the patch just uses the last read entry. I don't
> > > think supporting a more intricate way would be much use (such as keeping
> > > a list of DW_CC_program entries.)
> > 
> > What's the difference between the entry point and the main program?
> 
> The entry point is an implementation detail - like _start.  The main
> program is in user code, main() or "program foo".

I see.

I've read the Dwarf spec again, and it makes more sense to me now.
I'll try to review the patch later today.

Re: [PATCH] DW_AT_calling_convention support

[Daniel Berlin]

> > "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."
> > 
> > So the answer is yes and no. But I think the patch is valid as it
> > determines not the entry point, but the main program. As far as I am
> > aware you can have only one PROGRAM entry per FORTRAN program. If there
> > is more than one found, the patch just uses the last read entry. I don't
> > think supporting a more intricate way would be much use (such as keeping
> > a list of DW_CC_program entries.)
> 
> What's the difference between the entry point and the main program?

I would imagine the thinking is executables that can act as both shared 
libs, and as main programs (IE they have one entry point used when loaded 
as a module, one when used as loaded as a program).
A not-so-clear example of this would be a C++ program that can act as a 
shared lib and an executable.

As a shared lib, it probably has some automatically run by the 
runtime linker entry point that deals with exception registration and 
whatnot, but as a main program, this is probably done from main.

Thus, the main program is "main", but the entry points are "main" and 
"initialize_exceptions".
> 

Re: [PATCH] DW_AT_calling_convention support

[Andrew Cagney]

> Yep, that's about what I had in mind.  How about:
> 
>   set_main_name ()
>   set_main_symbol ()
>   is_main_symbol ()
>     - if a main symbol is set, check if it is the same symbol
>     - otherwise, check if it has the same name as passed to
>       set_main_name
> 
> (with appropriate care for when we change object files.... to one
> without a DWARF-2 main symbol, even...)

Just BTW, be open minded (be willing to completly re-think) with 
set_main_name() et.al.  They were added to dress up a hack that came in 
via java.

Andrew