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

[via llvm-dev]

Hi Muhui,

If you are looking for a tool to provide a more human-friendly dump of the DWARF information, at Sony we have a tool called DIVA which might meet your needs.  dwarfdump is what you might call a "disassembler" for DWARF, while DIVA is more like a de-compiler.
https://github.com/SNSystems/DIVA

Hope this helps!
--paulr

From: Muhui Jiang [mailto:jiangmuhui at gmail.com]
Sent: Wednesday, October 24, 2018 10:29 PM
To: Robinson, Paul
Cc: rofirrim at gmail.com; llvm-dev
Subject: Re: [llvm-dev] multi-entry function (debug info)

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<mailto: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<mailto:rofirrim at gmail.com>]
Sent: Tuesday, October 23, 2018 12:08 PM
To: Robinson, Paul
Cc: jiangmuhui at gmail.com<mailto: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/32f74b6d/attachment-0001.html>