This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdb can't handle a DIE with both sibling and children
- From: Michael Elizabeth Chastain <mec at shout dot net>
- To: carlton at kealia dot com, hjl at lucon dot org
- Cc: gdb at sources dot redhat dot com
- Date: Thu, 31 Jul 2003 16:37:32 -0400
- Subject: Re: gdb can't handle a DIE with both sibling and children
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