Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Michael Elizabeth Chastain <mec@shout.net>
To: carlton@kealia.com, hjl@lucon.org
Cc: gdb@sources.redhat.com
Subject: Re: gdb can't handle a DIE with both sibling and children
Date: Thu, 31 Jul 2003 20:37:00 -0000	[thread overview]
Message-ID: <200307312037.h6VKbWve026340@duracef.shout.net> (raw)

David Carlton asks:

> So: what does it mean for a subroutine to have another entry point?  I
> see that that entry point has a name; is that name visible to other
> compilation units, or only to the compilation unit in question?

The former.  The entry point is globally visible, just like the
main function name.

I never actually wrote an ENTRY statement, but here's a classic
FORTRAN example, where the body of "sine" and "cosine" would be
the same:

       double function sine (angle)
       double angle
       goto 10
       entry cosine (angle)
       angle = (3.14159265358979/4) - angle
       goto 10
    10 ... calculate the sine here ...
       return
       end

Of course, one could have implemented this as:

       double entry cosine (angle)
       return sine (3.14159265358979/4 - angle)
       end

But that's a waste of CPU time, back when the CPU was running
at 0.1 MHz.

For a modern example, it would be possible to implement those
pesky in-charge/not-in-charge constructors with one body of code
with 2 or 3 entry points.

> If it's only visible to the compilation unit in question, then the
> partial symtab probably doesn't have to know about it at all.  If it's
> visible outside the compilation unit (and if the compiler really is
> correct in putting DW_TAG_entry_points as children of
> DW_TAG_subroutines), then the partial symtab probably does have to know
> about it.

The main name and the entry names have the same visibility.
To the caller, 'sine' and 'cosine' are peers.

Michael C


             reply	other threads:[~2003-07-31 20:37 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-31 20:37 Michael Elizabeth Chastain [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-07-31 18:13 H. J. Lu
2003-07-31 18:19 ` David Carlton
2003-07-31 18:20 ` Daniel Jacobowitz
2003-07-31 18:27   ` H. J. Lu
2003-07-31 18:47     ` Daniel Jacobowitz
2003-07-31 19:36   ` David Carlton
2003-07-31 19:56     ` H. J. Lu
2003-07-31 20:02       ` Daniel Jacobowitz
2003-07-31 20:22         ` H. J. Lu
2003-07-31 20:29           ` Daniel Jacobowitz
2003-07-31 20:58             ` H. J. Lu
2003-07-31 21:01               ` Daniel Jacobowitz
2003-07-31 20:29           ` David Carlton
2003-07-31 20:13       ` David Carlton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200307312037.h6VKbWve026340@duracef.shout.net \
    --to=mec@shout.net \
    --cc=carlton@kealia.com \
    --cc=gdb@sources.redhat.com \
    --cc=hjl@lucon.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox