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

[David Blaikie via llvm-commits]

On Fri, Sep 8, 2017 at 5:08 PM Adrian Prantl via Phabricator <
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.

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.

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.

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

- 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170909/6ad3752f/attachment.html>