<div dir="ltr">Hi paulr<div><br></div><div>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</div><div><br></div><div>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</div><div><br></div><div>Regards</div><div>Muhui</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr"><<a href="mailto:paul.robinson@sony.com">paul.robinson@sony.com</a>> 于2018年10月24日周三 下午11:54写道：<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div class="m_-7723082026316966151WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">--paulr<u></u><u></u></span></p>
<p class="MsoNormal"><a name="m_-7723082026316966151__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></a></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Roger Ferrer Ibáñez [mailto:<a href="mailto:rofirrim@gmail.com" target="_blank">rofirrim@gmail.com</a>]
<br>
<b>Sent:</b> Tuesday, October 23, 2018 12:08 PM<br>
<b>To:</b> Robinson, Paul<br>
<b>Cc:</b> <a href="mailto:jiangmuhui@gmail.com" target="_blank">jiangmuhui@gmail.com</a>; LLVM-Dev<br>
<b>Subject:</b> Re: [llvm-dev] multi-entry function (debug info)<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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.</span><u></u><u></u></p>
</div>
</div>
</blockquote>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</blockquote></div>