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

Rui Ueyama ruiu at google.com
Wed Feb 11 16:37:56 PST 2015


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/20150211/2c779dd8/attachment.html>


More information about the llvm-commits mailing list