[llvm-dev] [yaml2obj] GSoC-20: Add DWARF support to yaml2obj

David Blaikie via llvm-dev llvm-dev at lists.llvm.org
Tue Mar 31 11:06:47 PDT 2020


On Tue, Mar 31, 2020 at 11:01 AM Adrian Prantl <aprantl at apple.com> wrote:

>
>
> On Mar 31, 2020, at 10:55 AM, David Blaikie <dblaikie at gmail.com> wrote:
>
> +1 to all that & cc'ing a few of the usual suspects as FYI
>
> On Tue, Mar 31, 2020 at 10:36 AM Pavel Labath via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>>
>>
>> For me personally, the ability to write/edit syntactically correct dwarf
>> easily is much more important than being able to generate "incorrect"
>> dwarf -- I'm perfectly happy to continue to write the latter in
>> assembly, but there is a lot that could be improved about the experience
>> of writing "correct" dwarf. Ideally, I'd have a mode where I can just
>>
>
> Do we think that yaml2obj is the best format for this, or would high-level
> DWARF DIE *assembler directives *be a more useful abstraction level? If
> you think about the .loc directive, there is actually some prior art in
> assembler.
>

.loc is necessary because it depends on encoding bit lengths of intervening
instructions, etc. Otherwise the line table would be like other DWARF
sections and not involve assembler-awareness.

I don't think it'd be a great idea to add the complexities of DWARF
emission to the assembler (except where it's fundamentally necessary, like
debug_line/.loc) - it'd be a lot of surface area to expose to users of
LLVM, support in the future as DWARF standards change, etc.


>
> -- adrian
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200331/ecd86281/attachment.html>


More information about the llvm-dev mailing list