<div dir="ltr"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 16, 2023 at 8:28 AM Ben Woodard via Dwarf-discuss <<a href="mailto:dwarf-discuss@lists.dwarfstd.org">dwarf-discuss@lists.dwarfstd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>I was looking at 2 level location tables
<a href="https://dwarfstd.org/issues/140906.1.html" target="_blank">https://dwarfstd.org/issues/140906.1.html</a> and can see how it could
improve things there. One thing that I noticed about it was that
it was based on some prior art done in HP-UX. <br>
</p>
<p>A nut that I have been trying to crack for a few years but
haven't really figured out comes from the performance tools,
binary analysis people and I could even make use of it for my ABI
work. They would really like something that I've been calling
"inverted location lists". Location lists are basically a function
(yes I know it is technically a relation but let's not quibble
about that right now):</p>
<blockquote>
<p>f( PC, "variable") -> location description</p>
</blockquote>
<p>This totally makes sense in the context of a debugger where the
context of the lookup includes the PC, and the user inputs the
symbolic name of the variable. The point that I try to make is
DWARF is not just for debuggers anymore. A much broader range of
consumers is emerging.<br>
</p>
<p>In the context of performance tools, they need:</p>
<blockquote>
<p>f( PC, <concrete> location) -> symbolic name</p>
</blockquote>
<p>The reason why I specify "concrete" location is because it is
never going to be a literal constant or an implicit or a DWARF
expression or any of the other things along those lines. It is
going to be an address or a register, things that have concrete
existence. <br></p></div></blockquote><div><br></div><div>lldb has a version of this function implemented in the functions StackFrame::GuessValueForAddress/GuessValueForRegisterAndOffset.</div><div><br></div><div>- Kyle <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
</p>
<p>Here are the use cases for this that have come up:</p>
<ul>
<li>For performance tools, they have some piece of code which is
not performing as it should. The tools show them that they are
getting a large number of cache misses between this PC and
another PC. They can disassemble the machine code and they see a
handful of instructions. To be able to figure out what is wrong
they need to associate the operands of these instructions to
what they refer to at the source level. Doing this disassembled
optimized machine code and then associating the data accesses
within it back to constructs within the source language really
puts this level of analysis is the domain of experts and must be
done by hand. Because of the limited information currently
provided by DWARF it is not something that can be coded into a
tool. <br>
</li>
<li>Within ABI analysis there are a few cases where compilation
options can change the calling convention of a function
sufficiently enough that it can create an ABI mismatch. The
simple example that illustrates the point is SSE. You can pass
vector operands by value in vector registers. However, if you
compile a program without SSE then it is passed by reference. So
in the ABI testing program, if I take the locations of the
formal parameters at the call site and then use an inverted
location list to look up what variables exist at those locations
in the called function, if they don't match then I have an ABI
problem. <br>
</li>
<li>One binary analysis use case is quite similar to the ABI use
case, they see a call instruction, they can look up the target
of the call to find the function prototype. From that they can
figure out where the parameters to the function call are at the
time of the call. However, they want to know in the calling
scope what symbolic name in the source language for the
parameter in a particular location at the time of the call.
Simple example: find all the examples of "dlopen" calls - what
library name is being opened, is it something that we can
determine from static analysis or is it something read from a
config file...<br>
</li>
</ul>
<p>What all three of us have tried doing with limited success is
taking the location list data and then inverting the mappings. The
problem is that this is far from complete and generating that data
is very computationally expensive.</p>
<p>I've looked for prior art to see if someone had come up with a
solution to this but I haven't found any. The allusion to the
HP-UX two level line maps is something that I had never come
across before. Since the combined experience of this group is much
deeper than what I have, does anybody know of any prior art that I
can use as a basis for a DWARF feature enhancement issue?</p>
<p>-ben</p>
<p><br>
</p>
</div>
-- <br>
Dwarf-discuss mailing list<br>
<a href="mailto:Dwarf-discuss@lists.dwarfstd.org" target="_blank">Dwarf-discuss@lists.dwarfstd.org</a><br>
<a href="https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss" rel="noreferrer" target="_blank">https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss</a><br>
</blockquote></div></div>