<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hi Pavel,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 5, 2019 at 8:31 AM Pavel Labath via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hello all,<br>
<br>
I have just posted a large-ish patch series for review (D58971, D58973, <br>
D58975, D58976), and I want to use this opportunity to draw more <br>
attention to it and highlight various bikeshedding <br>
opportunities^H^H^Htopics for discussion :).<br>
<br>
The new tool is called core2yaml, and it's goal is to fill the gap in <br>
the testing story for core files. As you might know, at present, the <br>
only way to test core file parsing code (*) is to check in an opaque <br>
binary blob and have the debugger open that. This presents a couple of <br>
challenges:<br>
- it's really hard to review what is inside the core file<br>
- one has to jump through various hoops to create a "small" core file<br>
This tools fixes both issues by enabling one to check in text files, <br>
with human-readable content. The yaml files can also be easily edited to <br>
prune out the content which is not relevant for the test. While that's <br>
not my goal at present, I am hoping that this will one day enable us to <br>
write self-contained tests for the unwinder, as the core file can be <br>
used to synthesize (or capture&reduce) interesting unwinder scenarios.<br>
<br>
Since I also needed to find a home for the new code I was writing, I <br>
thought this would be good opportunity to create a new library for <br>
various stuff. The goals I was trying to solve are:<br>
- make the yaml code a library. The reason for that is that we have a <br>
number of unittests using checked in binaries, and I thought it would be <br>
nice to be able to convert those to use yaml representation as well.<br>
- make the existing minidump parsing code more easily accessible. The <br>
parsing code currently lives in source/Plugins/Process/minidump, and is <br>
impossible to use it without pulling in the rest of lldb (which the tool <br>
doesn't need).<br>
The solution I came up with here is a new "Formats" library. I chose a <br>
fairly generic name, because I realized that we have code for <br>
(de)serializing a bunch of small formats, which don't really have a good <br>
place to live in. Currently I needed a parser for linux /proc/PID/maps <br>
files and minidump files, but I am hoping that a generic name would <br>
enable us to one day move the gdb-remote protocol code there (which is <br>
also currently buried in some plugin code, which makes it hard to depend <br>
on from lldb-server), as well as the future debug-info-server, if it <br>
ever comes into existence.<br>
<br>
Discussion topic #1: The library name and scope.<br>
There are lost of other ways this could be organized. One of the names I <br>
considered was "BinaryFormat" for symmetry with llvm, but then I chose <br>
to drop the "Binary" part as it seemed to me we have plenty of <br>
non-binary formats as well. As for it's dependencies I currently have it <br>
depending on Utility and nothing else (as far as lldb libraries go). I <br>
can imagine using some Host code might be useful there too, but I would <br>
like to avoid any other lldb dependencies right now. Another question is <br>
whether this should be a single library or a bunch of smaller ones. I <br>
chose a single library now because the things I initially plan to put <br>
there are fairly small (/proc/pid/maps parser is 200 LOC), but I can see <br>
how we may want to create sub-libraries for things that grow big (the <br>
debug-info server code might turn out to be one of those) or that have <br>
some additional dependencies.<br></blockquote><div><br></div><div>I don't have strong opinions here, nor do I have a better suggestion for the name.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Discussion topic #2: tool name and scope<br>
A case could be made to integrate this functionality into the llvm <br>
yaml2obj utilities. Here I chose not to do that because the minidump <br>
format is not at all implemented in llvm, and I do not see a use case <br>
for it to be implemented/moved there. A stronger case could be made to <br>
put the elf core code there, since llvm already supports reading elf <br>
files. While originally being in favour of that, I eventually adopted <br>
the view that doing this in lldb would be better because:<br>
- it would bring more symmetry with minidumps<br>
- it would enable us to do fine-grained yamlization for things that we <br>
care about (e.g., registers), which is something that would probably be <br>
uninteresting to the rest of llvm.<br></blockquote><div><br></div><div>I don't know much about the minidump format or code, but it sounds reasonable for me to have support for it in yaml2obj, which would be a sufficient motivation to have the code live there. As you mention in your footnote, MachO core files are already supported, and it sounds like ELF could reuse a bunch of existing code as well. So having everything in LLVM would give you even more symmetry. I also doubt anyone would mind having more fine grained yamlization, even if you cannot use it to reduce a test it's nicer to see structure than a binary blob (imho). Anyway, that's just my take, I guess this is more of a question for the LLVM mailing list.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Discussion topic #3: Use of .def files in lldb. In one of the patches a <br>
create a .def textual header to be used for avoiding repetitive code <br>
when dealing various constants. This is fairly common practice in llvm, <br>
but would be a first in lldb.<br></blockquote><div><br></div><div>I think this is a good idea. Although not exactly the same, we already got our feet wet with a tablegen file in the driver. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Discussion topic #4: Overlap with "process plugin dump". This tool has <br>
some overlap with the given command for minidump files, which also <br>
provides a textual description of minidump files. In case we are ok with <br>
tweaking the interface of that command slightly (and ok with some yaml <br>
artefacts in it's output), it should be possible to reimplement that <br>
command on top of the yaml serialization library.<br>
<br>
Discussion topic #5: Anything else I haven't thought of.<br>
<br>
regards,<br>
pavel<br>
<br>
(*) This is not entirely true for MachO core files, where yaml2obj is <br>
already able to convert the core files into text form. However, it is <br>
definitely true for ELF and minidump core files, and even the MachO yaml <br>
for isn't that well suited for manual viewing or reduction.<br>
_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
</blockquote></div></div></div></div></div>