<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Sep 8, 2017 at 5:08 PM Adrian Prantl via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">aprantl added a comment.<br>
<br>
I played around with how we could generate testcases for this.<br>
<br>
- I'm absolutely certain that yaml2obj (the standalone tool) is too low-level to do this. Having to manually update the object file header (or Mach-O load commands) every time a section changes in size is not doable unless you are starting from an existing object file and only modifying a couple bytes to inject, e.g., an error.<br>
- Using just the yaml2obj DWARF emitter like in the `DWARFDebugInfoTest.cpp` unittest is slightly better, but you still have to manually update the size of the CU header and compute all offsets by hand. Plus IMHO the use of yaml in a string constant is kind of weird., but I can get used to it.<br>
- Using assembler allows using labels, which gets rid off all the error-prone offset calculation, but on the other hand is much more verbose and low-level than some aspects of yaml2obj.<br>
- Using LLVM IR is much more compact than all of the above, but it has the drawback that we can only represent DWARF that LLVM can generate,<br>
- Source code is the most compact representation, but difficult to integrate into the LLVM testsuite because of the frontend dependency. It also restricts what DWARF we can generate even more.<br>
<br>
What I would want is a format where I can specify DWARF at the same level of abstraction that dwarfdump is presenting. The easiest way to achieve this is probably to generate the DWARF programmatically in a unit test using the same API that yaml2obj is using internally.</blockquote><div><br>This is sort of where Greg & I got to, sort of - except using LLVM's DWARF generation APIs, rather than the YAML.<br><br>I'm not really sure the YAML APIs would be shoretr than the YAML itself - though I do like APIs rather than embedded text, to a degree.<br><br>For myself - I feel like something like the YAML format, but where certain parts can be omitted/defaulted would be ideal. (alternatively I'd probably be OK with an API version of the same - but I think we'll end up finding YAML encoding to be more versatile - possibly with tools to generate YAML from existing objects, etc)<br><br>So, for example - a YAML format in which, if you omit the CU length, it's computed - but you can specify it when you want to override it with something bogus/interesting.<br><br>Similarly one in which you can omit the abbrev number for a DIE and have it generate abbrevs for you implicitly - or you can override it when you want to make something weird/broken/etc.<br><br>I don't know how much work that'd be - and certainly folks (some of them CC'd here - Chris & Lang) have disagreed with me about whether this is a viable path forward for tasks like this (object file formats/parsing/testing have similar issues - and I imagine we'd want to build the DWARF stuff on top of a general object file abstraction with similar features ("I can write the ELF section headers, or I can leave them out and let them be generated - when I'm focusing on writing DWARF tests, etc"))<br><br>- Dave<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> This way I can at least write code to calculate all the offsets. It would be kind of cute to write a tool that takes dwarfdump-like output as input and emits a yaml2obj-like yaml file, but I feel that that would be overkill since it isn't going to be very useful outside of this patch.<br>
<br>
I will think some more about this.<br>
<br>
<br>
Repository:<br>
  rL LLVM<br>
<br>
<a href="https://reviews.llvm.org/D36993" rel="noreferrer" target="_blank">https://reviews.llvm.org/D36993</a><br>
<br>
<br>
<br>
</blockquote></div></div>