[PATCH] LLD: Remove YAML/Native round-trip passes

[Rui Ueyama]

Ping?

On Wed, Feb 11, 2015 at 4:37 PM, Rui Ueyama <ruiu at google.com> wrote:

> I found that Writing and reading Native files from YAML reader is actually
> tricky. Readers generally don't need a linking context, but writers do. So
> it's not easy to call a writer from a reader. Seems it needs a plumbing
> work.
>
> Then I tried to convert a YAML file to Native using yaml2obj
> -format=native. yaml2obj didn't actually support Native format because
> Native format lives only in LLD. Yet it's intended to be an alternative,
> hopefully better object file format, it's not supported by anyone except
> the linker. There's no consumer producing a file in that file format.
>
> I started feeling I'm just wasting time. There are a lot of other things I
> need to do to make LLD a production quality linker, and this is not only
> non-productive but is actually counter-productive. Can you guys approve
> this patch so that I can submit this now?
>
> On Wed, Feb 11, 2015 at 2:08 PM, Rui Ueyama <ruiu at google.com> wrote:
>
>> On Tue, Feb 10, 2015 at 7:27 PM, Rafael Espíndola <
>> rafael.espindola at gmail.com> wrote:
>>
>>> I really like this.
>>>
>>> Every object file has peculiarities. MachO  has scattered relocations.
>>> Mips elf has many in one relocations.
>>>
>>> If we, with the handsight of having built a linker, create a rounder
>>> wheel, it will be just another file format. We will still have to parse it
>>> and report broken files. It will have to be able to represent the
>>> constructs that currently use the various features of existing formats, but
>>> calling it "native" and requiring direct mapping to it seems counter
>>> productive.
>>>
>> I totally agree.
>>
>> What I'm thinking now is to convert a YAML file to Native and read it
>> back before doing anything to that YAML file, assuming YAML and Native are
>> compatible. YAML reader should be well-tested because there are many tests
>> written in YAML. So that test should be enough to test Native.
>>
>>
>>> On Feb 6, 2015 9:40 PM, "Rui Ueyama" <ruiu at google.com> wrote:
>>>
>>>> The round-trip passes were introduced in r193300. The intention of
>>>> the change was to make sure that LLD is capable of reading end
>>>> writing such file formats.
>>>>
>>>> But that turned out to be yet another over-designed stuff that had
>>>> been slowing down everyday development.
>>>>
>>>> The passes ran after the core linker and before the writer. If you
>>>> had an additional piece of information that needs to be passed from
>>>> front-end to the writer, you had to invent a way to save the data to
>>>> YAML/Native. These passes forced us to do that even if that data
>>>> was not needed to be represented neither in an object file nor in
>>>> an executable/DSO. It doesn't make sense. We don't need these passes.
>>>>
>>>> http://reviews.llvm.org/D7480
>>>>
>>>> Files:
>>>>   include/lld/Passes/RoundTripNativePass.h
>>>>   include/lld/Passes/RoundTripYAMLPass.h
>>>>   lib/CMakeLists.txt
>>>>   lib/Driver/CMakeLists.txt
>>>>   lib/Driver/Driver.cpp
>>>>   lib/Passes/CMakeLists.txt
>>>>   lib/Passes/Makefile
>>>>   lib/Passes/RoundTripNativePass.cpp
>>>>   lib/Passes/RoundTripYAMLPass.cpp
>>>>   lib/ReaderWriter/CMakeLists.txt
>>>>   lib/ReaderWriter/CoreLinkingContext.cpp
>>>>   lib/ReaderWriter/ELF/CMakeLists.txt
>>>>   lib/ReaderWriter/ELF/ELFLinkingContext.cpp
>>>>   lib/ReaderWriter/ELF/Makefile
>>>>   lib/ReaderWriter/MachO/CMakeLists.txt
>>>>   lib/ReaderWriter/MachO/MachOLinkingContext.cpp
>>>>   lib/ReaderWriter/PECOFF/CMakeLists.txt
>>>>   test/elf/Mips/pc23-range.test
>>>>   test/elf/roundtrip.test
>>>>   test/lit.cfg
>>>>   tools/lld/Makefile
>>>>   unittests/DriverTests/Makefile
>>>>
>>>> EMAIL PREFERENCES
>>>>   http://reviews.llvm.org/settings/panel/emailpreferences/
>>>>
>>>> _______________________________________________
>>>> llvm-commits mailing list
>>>> llvm-commits at cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>>>
>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150212/61600189/attachment.html>