[PATCH] D36993: [llvm-dwarfdump] Print type names in DW_AT_type DIEs

Mon Sep 11 10:05:50 PDT 2017

> On Sep 8, 2017, at 5:14 PM, David Blaikie <dblaikie at gmail.com> wrote:
> 
> 
> 
> On Fri, Sep 8, 2017 at 5:08 PM Adrian Prantl via Phabricator <reviews at reviews.llvm.org <mailto:reviews at reviews.llvm.org>> wrote:
> aprantl added a comment.
> 
> I played around with how we could generate testcases for this.
> 
> - 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.
> - 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.
> - 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.
> - 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,
> - 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.
> 
> 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.
> 
> This is sort of where Greg & I got to, sort of - except using LLVM's DWARF generation APIs, rather than the YAML.
> 
> 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.

The YAML APIs are really just data structures that you populate then yamlize. I want to (and have partial patches) to rewrite Greg's dwarfgen APIs to use the YAML generation data.

> 
> 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)
> 
> 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.

Totally agree. I actually sent out a patch for review back in March (but it got lost), which allows the DIE length to be omitted and calculated during writing:

https://reviews.llvm.org/D30666 <https://reviews.llvm.org/D30666>

> 
> 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.

The Visitor infrastructure that I wrote for doing DIE length calculation could allow us to do more simplified yaml representations that would make it easier to write tests by hand, and could do things like generating abbrevs.

> 
> 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"))

All the DWARFYAML stuff is only connected for Mach-o at the moment, but it shouldn't be hard to connect up to ELF too. For the unit tests I added a path for creating DWARFContexts from StringMaps of MemoryBuffers where the key is the DWARF section name. This allows us to write unit tests without any interaction with the object files.

I think having flexibility in this tooling will make it easy to write tests of different kinds and with different levels of specificity, which in turn will encourage writing more tests.

-Chris

> 
> - Dave
>  
> 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.
> 
> I will think some more about this.
> 
> 
> Repository:
>   rL LLVM
> 
> https://reviews.llvm.org/D36993 <https://reviews.llvm.org/D36993>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170911/42c69c40/attachment.html>