similar to: RFC: Add DWARF support for yaml2obj

On 5/21/20, Adrian Prantl <aprantl at apple.com> wrote: > I think the example looks like it would be really useful for many categories > of testcases! > Will it still be possible to manually specify the .debug_abbrev section when > this is desired after you are done? Yes, I think it works. There are two ways to edit the .debug_abbrev section. i) Edit the "Attr:" and

Hi there, I'm proposing for the GSoC project: Add DWARF support to yaml2obj[1]. I've uploaded my proposal. If you have any suggestion or ideas, feel free to leave a comment[2]. Thanks! ------ [1] https://llvm.org/OpenProjects.html#llvm_dwarf_yaml2obj [2] https://docs.google.com/document/d/1miCuMQEX8WZ9_hWXWQtOYTA4JAK-yDnPV9vyO_d5vzE/edit?usp=sharing -- Best Regards, Xing

I believe the compiler will generate a .debug_ranges section if you use -ffunction-sections, since the addresses of sections will be non-contiguous. From there, you should be able to edit the .debug_ranges assembly as needed (replace references to symbols with 0s in the .debug_ranges content) to get the exact behaviour you want (I'm assuming you don't want to have to hand-edit a

On 31/03/2020 18:29, Adrian Prantl via llvm-dev wrote: > It's great to see someone interested in improving yaml2obj! > > As far as I'm concerned, the main problem with yam2obj for DWARF testcases is that at the moment, it is both too high-level and too low-level at the same time. For writing debug info testcases, yaml2obj at the moment does not add anything on top of assembler.

Hi Pavel, Thanks for your comments! On 5/21/20, Pavel Labath <pavel at labath.sk> wrote: > Hello Xing, > > I think the proposal looks very useful. I think it will be fairly tricky > to get all of the details right though. There is a lot of "inferring" > going on there, and getting that to work reliably and with predictable > results will need careful

(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

I think we have to be careful here. We might want flexibility to say "I want to use a specific class" without having to specify the exact DW_FORM. Sometimes, we might even end up in an ambiguous situation and not get the result we want. For example, in DWARFv4, the DW_AT_high_pc attribute has either a Constant or an Address class, which use completely different forms, but if we have just

> 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

I am adding -D k=v to yaml2obj, similar to clang -D. This makes it easy to generate {32-bit,64-bit} x {big-endian,little-endian} tests. --- !ELF FileHeader: Class: ELFCLASS[[BITS]] Data: ELFDATA2[[ENCODE]] Type: ET_DYN Machine: EM_X86_64 # RUN: yaml2obj -D BITS=32 -D ENCODE=LSB %s -o %t.32le # RUN: yaml2obj -D BITS=32 -D ENCODE=MSB %s -o %t.32le # RUN: yaml2obj

?The idea itself is indeed good. Regarding to escaping: I think we should have it. Imagine the following example (I've took it from D73828). --- !ELF FileHeader: Class: ELFCLASS[[BITS]] Data: ELFDATA2LSB Type: ET_EXEC Machine: EM_386 # RUN: yaml2obj %s --docnum=4 -D BITS=32 -o %t-32bit.o # RUN: yaml2obj %s --docnum=4 -D BITS=64 -o %t-64bit.o Without escaping it would

Also, why does it say yaml2py?: yaml2obj takes a YAML description of an object file and converts it to a binary file. $ yaml2py input-file .. program:: yaml2py --Sean Silva On Thu, Sep 20, 2012 at 4:59 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Wed, Sep 19, 2012 at 8:25 PM, Sean Silva <silvas at purdue.edu> wrote: >> Sphinx warns that yaml2obj

Hi, As far as I understand now it is impossible to generate ELF object file with relocation sections using yaml2obj tool. I plan to support ELF relocations in the yaml2obj. Does anybody work on it already or plan to start this task soon? -- Simon Atanasyan

On Thu, Sep 20, 2012 at 7:34 PM, Sean Silva <silvas at purdue.edu> wrote: > Also, why does it say yaml2py?: > > yaml2obj takes a YAML description of an object file and converts it to a binary > file. > > $ yaml2py input-file > > .. program:: yaml2py > > --Sean Silva > Oops. Well, yaml kinda looks like Python... Feel free to fix that. - Michael Spencer

Let's suppose that MCLinker folks are here already - I am a committer of this project :). Maybe I did not formulate my suggestion correctly. When I offer to "install" the yaml2obj and obj2yaml utilities I mean result of the "make install" command only. I do not suggest to include this utilities into any distributed binary packages. To be clear I attached the patch with

Great, thanks! Those results are about roughly what I was expecting. I assume "compilation time" is actually just the link time? I find it particularly interesting that the DWARFLinker rewriting solution produces the same size improvement in .debug_line as the fragmented DWARF approach. That suggests that in that case, fragmented DWARF output is probably about as optimal as it can get.

Sphinx warns that yaml2obj isn't included into any toctree. Where is a logical place to link this? --Sean Silva

Spoiler: the following only applies to Windows binary format handling. Potential for extending yaml2obj to support COFF debug directories<https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#debug-directory-image-only> recently came up during a code review<https://reviews.llvm.org/D70606#1873185>. Currently, its COFF

Now the yaml2obj and obj2yaml utilities used in LLVM and LLD projects tests only and not installed by the "make install" command. I think they might be also useful in third-party projects like MCLinker. I suggest to move these utilities into the "tools" category and install them together with other LLVM tools. Any objections or comments? -- Simon Atanasyan

On Wed, Sep 19, 2012 at 8:25 PM, Sean Silva <silvas at purdue.edu> wrote: > Sphinx warns that yaml2obj isn't included into any toctree. Where is a > logical place to link this? > > --Sean Silva No idea, which is why it's not linked :P. Add it anywhere you feel makes sense. - Michael Spencer

Hi, On Wed, Apr 2, 2014 at 1:03 AM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Mon, Mar 31, 2014 at 10:54 AM, Simon Atanasyan <simon at atanasyan.com> wrote: >> As far as I understand now it is impossible to generate ELF object >> file with relocation sections using yaml2obj tool. I plan to support >> ELF relocations in the yaml2obj. Does anybody work