[llvm-dev] multi-entry function (debug info)

[via llvm-dev]

Getting back to what the DWARF should look like, I solicited examples on the dwarf-discuss list.  gfortran emits sibling DW_TAG_subprogram entries for the SUBROUTINE and each ENTRY, which seems like a hack.  But both IBM XL Fortran and OpenVMS Fortran will emit a DW_TAG_subprogram for the SUBROUTINE, and it will have a child DW_TAG_entry_point for each ENTRY within the SUBROUTINE.  Each of these entries will have its own set of DW_TAG_formal_parameter entries, according to the spec.
This aligns with my expectation, that the ENTRY is "contained" within a SUBROUTINE, and the natural way for DWARF to represent this is by having entry_point children of the subprogram DIE.
--paulr

From: Roger Ferrer Ibáñez [mailto:rofirrim at gmail.com]
Sent: Tuesday, October 23, 2018 12:08 PM
To: Robinson, Paul
Cc: jiangmuhui at gmail.com; LLVM-Dev
Subject: Re: [llvm-dev] multi-entry function (debug info)


Regarding multi-entry functions, I'm aware of two cases where this occurs in a source language.  One is when you have optional parameters in C++, which effectively creates one or more overloads for the function; the other is PL/I which allows defining an entry label within the body of the function.  For the C++ case, I'd expect the front-end to create stubs that fill in the defaulted parameters and then tail-call the main function; in this case, each stub would have its own debug-info entry and be treated as its own independent function for debug-info purposes.  For PL/I, I would probably do the same, although I admit it has been a long time since I did any PL/I programming and I never worked on a PL/I compiler.

Another example of source language with functions that can have more than entry point is Fortran via the ENTRY statement. I think most compilers use an extra integer parameter to discriminate between the different entry points at the call sites.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181024/380f677e/attachment-0001.html>