[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