<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">I agree with James about using `-fstack-size-section` to get static stack size information. Deriving that info from DWARF seems like a lot of work; I imagine you’d have to parse all of the locations within a function, looking for frame
offsets. Even then the result would be incomplete because it would describe only the stack slots used by declared variables. Temporaries and even spill slots probably would not be accounted for.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Regarding partitioning DWARF, just for completeness I’ll say that we did also (at least briefly) look at using DWARF partial-units, but the size overhead seemed like it would not be a net win.<o:p></o:p></p>
<p class="MsoNormal">--paulr<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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 #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> llvm-dev <llvm-dev-bounces@lists.llvm.org> <b>On Behalf Of
</b>James Henderson via llvm-dev<br>
<b>Sent:</b> Thursday, September 30, 2021 3:44 AM<br>
<b>To:</b> David Blaikie <dblaikie@gmail.com><br>
<b>Cc:</b> llvm-dev@lists.llvm.org; Youssefi, Anna <a-youssefi@ti.com><br>
<b>Subject:</b> Re: [llvm-dev] unified debug information despite function/data sections flags<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">Yep, I took a look at this last year/early this year, but never really came up with a fully functioning prototype that was actually efficient enough, and have since switched teams, so haven't had the time to work on it further.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">You can see my lightning talk from last year on the topic here:
<a href="https://urldefense.com/v3/__https:/www.youtube.com/watch?v=0y6TlfFhCsU__;!!JmoZiZGBv3RvKRSx!tN8gFEUPCxDRSu56DvwynukFPsnIfjTun8qHS8i2OIBJTTXVldfiOutPoBwVBScCog$">
https://www.youtube.com/watch?v=0y6TlfFhCsU</a>, and a mailing thread where I discussed it further here:
<a href="https://urldefense.com/v3/__https:/lists.llvm.org/pipermail/llvm-dev/2020-November/146469.html__;!!JmoZiZGBv3RvKRSx!tN8gFEUPCxDRSu56DvwynukFPsnIfjTun8qHS8i2OIBJTTXVldfiOutPoByLU9AFKw$">
https://lists.llvm.org/pipermail/llvm-dev/2020-November/146469.html</a>. The main issue I ran into was the number of hard-coded relative references within DWARF. Every single one of these needs to be updated at link time, if any of the data is dropped, or the
DWARF will end up invalid. To do this, I had to add relocations to the DWARF which patched the relevant fields at link time, based on the final computed offset, but this had a serious performance cost in the linker (not to mention any potential cost in the
assembler). This approach is certainly possible for the most part, at least for .debug_line and .debug_info (it's not necessarily clear whether it can be done with some of the other DWARF sections, although the benefits in most of them aren't particularly
clear), but the difficulty is getting it to be fast.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I'd be happy to discuss this further, and provide any feedback on other ideas, if you have any, but currently have no plans to continue this work at this time myself.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">By the way, if you are using the DWARF for stack usage analysis, have you considered the .stack_sizes section? This emits a section that contains the stack size of every function in the output, and can be dumped using llvm-readobj. It is
split up so that the linker can strip bits that reference dead data, so you should only end up with the actually useful information in the output.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">James<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Thu, 30 Sept 2021 at 07:51, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<o:p></o:p></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">You can differentiate dead function descriptions from others on most platforms by checking if the low_pc == 0. If 0 is a valid instruction address on your architecture, you can use an lld feature to set a more authoritative/unambiguous
tombstone value for dead code addresses, passing something like:<br>
<br>
<o:p></o:p></p>
<pre><i><span style="color:black"> -z 'dead-reloc-in-nonalloc=.debug_ranges=0xfffffffffffffffe'<o:p></o:p></span></i></pre>
<pre><i><span style="color:black"> -z 'dead-reloc-in-nonalloc=.debug_loc=0xfffffffffffffffe'<o:p></o:p></span></i></pre>
<pre><i><span style="color:black"> -z 'dead-reloc-in-nonalloc=.debug_*=0xffffffffffffffff'</span></i><span style="color:black"><o:p></o:p></span></pre>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">to the linker.<br>
<br>
As for reducing debug info size by omitting debug info descriptions of dead code - Apple/MachO's dsymutil does this, and I believe Alexey Lapshin is working on trying to get similar behavior into lld, possibly (or as a post-link tool).<br>
<br>
There's also the possibility of using comdats to make the linker's job easier - I think there might be ways to structure the DWARF into chunks that could be deduplicated and dropped naturally by a linker's existing comdat support, but I haven't fully prototyped
it. I think there was a thread a while back with JHenderson and others discussing this possibility further.<br>
<br>
- Dave<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">On Wed, Sep 29, 2021 at 12:50 PM Youssefi, Anna via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<o:p></o:p></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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Hi,<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I was wondering if there are any plans to separate debug information into distinct sections accordingly when the compiler flags -ffunction-sections and/or -fdata-sections are used.
If an unreferenced function is removed from the link, it makes no sense for its associated debug information to still be included. As we rely on the debug information for stack usage analysis, we wind up displaying stack usage statistics for unreferenced
functions that were eliminated from the link if debug information for any other referenced functions is in the same debug section. It seems that others have run into this problem previously so I wanted to check whether there are any plans to change the behavior.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Thanks,<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Anna Youssefi<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Texas Instruments, Codegen group<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!tN8gFEUPCxDRSu56DvwynukFPsnIfjTun8qHS8i2OIBJTTXVldfiOutPoBwG7e4e1Q$" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</body>
</html>