(original) (raw)

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@gmail.com\]
Sent: Tuesday, October 23, 2018 12:08 PM
To: Robinson, Paul
Cc: jiangmuhui@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.