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

[Muhui Jiang via llvm-dev]

Hi paulr

Thanks for your answer and sorry for the late reply. Actually, I am not
very interested in the cases that occur in the source language.  What I
want to know is that when there are more than one entry point, how does
dwarf represent this. Now I have the idea according to your answer. Thanks

I would like to ask more about the dwarf debugging information. As there
are many components/ tags in the debugging information. When I use the
dwarfdump -debug-info to dump the debugging information. I found it would
be rather difficult to parse the dumped information. Does llvm provide any
tools or do you have any suggestions on parsing the dwarf debugging
information? Many Thanks

Regards
Muhui


<paul.robinson at sony.com> 于2018年10月24日周三 下午11:54写道：

> 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/20181025/6998b0a1/attachment.html>