similar to: [LLVMdev] [yaml2obj] ELF relocation support

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

On Wed, Apr 2, 2014 at 2:27 PM, Michael Spencer <bigcheesegs at gmail.com>wrote: > On Wed, Apr 2, 2014 at 10:54 AM, Simon Atanasyan <simon at atanasyan.com> > wrote: > > 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

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

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

Hi, There are more than one MIPS relocations which need GOT entry creation. Let's consider two of them R_MIPS_GOT16 and R_MIPS_CALL16 [1]. R_MIPS_GOT16 is applicable to local and external symbols and performs a different calculation in each cases [2]. R_MIPS_CALL16 is applicable to external symbols only and a linker should show an error if it finds R_MIPS_CALL16 with a local target. Now LLD

On Mon, Apr 20, 2015 at 1:44 AM, Shankar Easwaran <shankarke at gmail.com> wrote: > Attached patch fixes the issue. Thanks for the quick fix. The patch LGTM if you add a test case. Unfortunately yaml2obj does not support duplicated section names but we can use a binary input file. -- Simon Atanasyan

Nothing wrong with going ahead with a temporary measure if the temporary measure is reasonable (besides the discussion if checking in binary files is desirable). Even if you plan to add a test written in YAML, it's better to check in a binary at least for now than checking it in without any tests. On Mon, Apr 20, 2015 at 7:59 AM, Shankar Easwaram <shankarke at gmail.com> wrote: > I

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

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 Shankar, On Tue, Feb 12, 2013 at 10:46 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Author: shankare > Date: Tue Feb 12 12:46:53 2013 > New Revision: 174990 > > URL: http://llvm.org/viewvc/llvm-project?rev=174990&view=rev [...] > ELFDefinedAtom<ELFT> *createDefinedAtomAndAssignRelocations( > StringRef symbolName, StringRef

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

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, FYI LLD cannot handle ELF sections with non-unique names. An object file with such sections can be generated by the Clang since r234143. I am not sure that Clang works absolutely correct but bfd linker works fine. Right now I do not have a time to investigate this problem. If nobody take, I will try to solve it later. Here is the reproduction script for x86_64 host: $ cat test.cc template

?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

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

> 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

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

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

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