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
next 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