<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 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.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">
<div class="WordSection1">
<p class="MsoNormal" style="margin-left:.5in">What's DW_FORM_line_str/debug_line_str for? (so the line table can be kept while strippnig the rest of the debug info, including its strings?)<span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Exactly. In prior versions of DWARF the line-table strings were always embedded directly in .debug_line so it was possible to strip
everything else. With v5 we wanted to make sure it was straightforward to keep doing that.<o:p></o:p></span></a></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in">Inconveniently, DWARFFormValue assumes it is looking at a .debug_info<br>
section, and picks up its relocations from a DWARFUnit. But if we're<br>
using DWARFFormValue to decode data from .debug_line, then it needs a<br>
different relocation map.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><br>
I'm going to assume there's going to be similar inconvenience on the other side (the emission side).<br>
<br>
<span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I hope not. Emission of the .debug_line section is already prepared to conjure up relocations (to various .text sections) as needed, and I would anticipate
that once we can get the line-table strings to come out in another section, emitting the corresponding relocations would be quite natural.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in">Any idea what form you'll be using for LLVM's emisison? LLVM currently only emits strp - figure the same for the line table? Or more likely to use _string unconditionally?<span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:4.8pt"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I'd start out with _string. LLVM currently only emits strp for actual attributes in the .debug_info section; but these pathname strings
are (currently for v4) dumped directly into the .debug_line section, and by specifying FORM_string I can keep doing that. Also this is the form that the first round of dumper changes will be able to handle.
</span><span style="font-size:11.0pt;font-family:Wingdings;color:#1F497D">J</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:4.8pt"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Later on we can change emission to use _line_strp; that entails emitting the actual strings into a different section. Once we do
that, it becomes possible for the linker to do string pooling on the path names (the original motivation for this more complicated header format).<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:4.8pt"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:4.8pt"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I hope to be able to post the first patch next week.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:4.8pt"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thanks!<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:4.8pt"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">--paulr<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:4.8pt"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<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""> David Blaikie [mailto:dblaikie@gmail.com]
<br>
<b>Sent:</b> Friday, April 28, 2017 12:10 PM<br>
<b>To:</b> Robinson, Paul; llvm-dev@lists.llvm.org<br>
<b>Subject:</b> Re: [llvm-dev] [DWARFv5] The new line-table section header<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Thu, Apr 27, 2017 at 1:12 PM Robinson, Paul via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">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">
<p class="MsoNormal">The next feature on my DWARF 5 list is the line-table header. While this<br>
is pretty easy generate, it is a real bear to parse, so I thought I should<br>
let y'all know what I'm up to and why as I head out to the yak farm. Any<br>
thoughts and suggestions would be very much appreciated.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><br>
Thanks a bunch for sending this email! - I'd love to see more like this when large pieces are undertaken in LLVM for just these reasons, so we can all get a sense of where things are aiming, the motivation, etc.<br>
<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">
<p class="MsoNormal">The v5 directory and file tables no longer have a fixed format; instead,<br>
we have a list of field descriptors followed by the fields for each entry<br>
in the directory or file table. Normally the directory table would have<br>
one descriptor:<br>
DW_LNCT_path, DW_FORM_string<br>
This tells us each entry contains a pathname encoded as an inline string.<br>
(Which is essentially how the v4 directory table is encoded.) However,<br>
because of the FORM code, we now have whole new worlds of complication<br>
regarding where the actual string might be. We might have DW_FORM_strp<br>
which puts the actual string in the .debug_string section; eventually we<br>
could have DW_FORM_line_str (pointing to .debug_line_str) <o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><br>
What's DW_FORM_line_str/debug_line_str for? (so the line table can be kept while strippnig the rest of the debug info, including its strings?)<br>
<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">
<p class="MsoNormal">or even<br>
DW_FORM_strx (indirecting through .debug_str_offsets).<br>
<br>
Conveniently, we have the DWARFFormValue class which knows how to decode<br>
data based on what the form code is.<br>
<br>
Inconveniently, DWARFFormValue assumes it is looking at a .debug_info<br>
section, and picks up its relocations from a DWARFUnit. But if we're<br>
using DWARFFormValue to decode data from .debug_line, then it needs a<br>
different relocation map.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><br>
I'm going to assume there's going to be similar inconvenience on the other side (the emission side).<br>
<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">
<p class="MsoNormal">It's only the string data that causes a problem; all the other kinds<br>
of data in the file table are constants, and retrieving constants<br>
with DWARFFormValue is no problem.<br>
<br>
<br>
I think the right tactic is a "top-down" approach, starting by teaching<br>
DWARFDebugLine to parse a v5 line-table header but support only<br>
DW_FORM_string for the paths. This should let me use an unmodified<br>
DWARFFormValue to parse the directory and file tables.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><br>
Any idea what form you'll be using for LLVM's emisison? LLVM currently only emits strp - figure the same for the line table? Or more likely to use _string unconditionally?<br>
<br>
In any case - if/when you have the right format support in llvm-dwarfdump, you could go ahead and implement the output code in LLVM's codegen, even before llvm-dwarfdump can handle every arcane format that any DWARF producer might decide to use. (& then you
can continue implementing those - but it'd get you the LLVM functionality sooner, rather than gating it on having a fully general parser)<br>
<br>
This approach has certainly been taken in the past - implementing enough dumping support as needed for LLVM's generation functionality & expanding as-needed.<br>
<o:p></o:p></p>
</div>
<p class="MsoNormal">From there, teaching DWARFFormValue to handle DW_FORM_strp from the<br>
.debug_line section should be pretty well motivated and it should be<br>
straightforward to see what's really needed in terms of the API.<br>
<br>
Once we get that far, I would hope that the line_str and strx<N> forms<br>
would not require much additional effort. Actually Wolfgang is<br>
separately working on the strx<N> forms so with any luck that would<br>
Just Work for the .debug_line section.<br>
<br>
Oh yeah, after all that I'd actually generate the v5 header from LLVM.<br>
The idea is that by then, I can use llvm-dwarfdump to validate it and<br>
be very confident that it would all work.<br>
<br>
Does all that sound like a plan? The alternative would be to try to<br>
teach DWARFFormValue to handle DW_FORM_strp from .debug_line up front,<br>
but I think we might rather go at this in smaller pieces.<br>
<br>
Thanks,<br>
--paulr<br>
<br>
_______________________________________________<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="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></p>
</div>
</body>
</html>