Adrian Prantl via llvm-dev
2020-Mar-31 18:01 UTC
[llvm-dev] [yaml2obj] GSoC-20: Add DWARF support to yaml2obj
> 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 <mailto: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 justDo 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. -- adrian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200331/01490860/attachment.html>
David Blaikie via llvm-dev
2020-Mar-31 18:06 UTC
[llvm-dev] [yaml2obj] GSoC-20: Add DWARF support to yaml2obj
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>
Fangrui Song via llvm-dev
2020-Mar-31 18:22 UTC
[llvm-dev] [yaml2obj] GSoC-20: Add DWARF support to yaml2obj
On 2020-03-31, Adrian Prantl via llvm-dev 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 <mailto: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. > >-- adrianI also find YAML tests unwieldy but for some tests (especiall malformed) we may have to use them because it is diffult for an assembly directive to produce invalid output (invalid offset/relocation/string table/etc). An assembly syntax can be conciser than its YAML counterpart, e.g. to describe a section: assembly: .section .foo,"a", at progbits YAML: - Name: foo Type: SHT_PROGBITS Flags: [ SHF_ALLOC ] A symbol table entry is similar. A YAML entry usually takes several lines of code. Another advantage of assembly syntax is that it is composable. To define a local symbol: label: To make it global: .globl label label: Some directives are more expressive, e.g. .file .loc An assembler even supports some meta programming features (macros). The syntax may be strange. We do need some composable directives to make DWARF tests easier to write/read.
Pavel Labath via llvm-dev
2020-Apr-24 13:21 UTC
[llvm-dev] [yaml2obj] GSoC-20: Add DWARF support to yaml2obj
(Reviving this thread because a code review reminded me I want to reply here. Sorry for the extremely long turnaround). On 31/03/2020 20:22, Fangrui Song wrote:> On 2020-03-31, Adrian Prantl via llvm-dev 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 <mailto: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. >> >> -- adrian > > I also find YAML tests unwieldy but for some tests (especiall malformed) > we may have to use them because it is diffult for an assembly directive > to produce invalid output (invalid offset/relocation/string table/etc). > > An assembly syntax can be conciser than its YAML counterpart, e.g. to > describe a section: > > assembly: .section .foo,"a", at progbits > YAML: - Name: foo > Type: SHT_PROGBITS > Flags: [ SHF_ALLOC ] > > A symbol table entry is similar. A YAML entry usually takes several > lines of code. > > Another advantage of assembly syntax is that it is composable. To define a > local symbol: > > label: > > To make it global: > > .globl label > label: > > Some directives are more expressive, e.g. .file .loc > An assembler even supports some meta programming features (macros). The > syntax may be strange. > > We do need some composable directives to make DWARF tests easier to > write/read.I am agree with David that we shouldn't add first class DWARF-generation directives to the assembler just for the sake of writing tests. However, I do see the appeal of assembler metaprogramming, and I have used it on occasion when generating some DWARF. A separate utility with some (meta-)programming facilities could be interesting, though it would be an additional burden to maintain, and I am not sure it is really needed (in tests, repetition is often better than complex control flow). I am curious about your comment on invalid relocations et al. I can see how that is interesting for testing binary utilities (and I don't think anyone wants to take that away), but I am not sure how useful is that in the context of DWARF testing, except maybe in a couple of low-level DWARF tests (which could be done in the traditional elf yaml and the DWARF could be written as a blob of bytes). If you have some examples like that, I'd very much like to about it. regards, pl