[PATCH] D11612: [lld][ELF2] Apply relocations.

Rafael EspĂ­ndola via llvm-commits llvm-commits at lists.llvm.org
Fri Aug 14 05:46:26 PDT 2015


> I'm not sure how you guys have decided on divvying up the work, but as a
> person that works within earshot of Michael, it seems that a significant
> factor to that is that many of the changes you make are antagonistic to the
> changes he is trying to make. Deleting dead code that is used by the patch
> he is trying to land or

The situation is perfectly symmetrical.

If the code is dead, it should be deleted. As Rui pointed out, many
were COFFism that he copied and failed to notice when s/COFF/ELF/.

We would also be further along if I didn't have to be the one
implementing code reviews on his code because he never replies to
them.

>>
>> I am *totally* opposed to
>> *ever* having a YAML test that can be written in assembly.
>>
>> If I can understand that entire YAML gunk is:
>>
>> foo:
>> .section bar
>>         call foo
>>
>
> I like seeing bytes and symbolized ELF spec names. That is what I know best.
> That is what anybody working on this linker will know. I don't know all the
> weird corners of gas syntax (+ LLVM extensions apparently), nor would I
> expect any linker developer to know that. I *would* expect any linker
> developer to know the symbolic constants (or at least be able to easily
> google them).
>
> The YAML file directly expresses the intent; yes there is lots of "gunk"
> surrounding it, but any linker developer knows how to skim that based on
> knowing the meaning of the symbolic constants. Do you find it hard to
> navigate the YAML files? We can improve the format if necessary if there is
> a particular pain point or two.
>
> To put it another way, every "gas directives" file I see in the test
> directory, my immediate reaction is wanting to assemble it and readobj it to
> see what it "actually" is feeding to the linker. I particularly like the
> YAML because like readobj output, it is telling you pretty straight up what
> is there. One doesn't need to guess what flags the assembler set on that
> section, whether a particular relocation kind actually ends up in the
> output, etc. You just see it immediately in your editor.

Too bad. You have 0 lines of code on the new linker. You are most
certainly not helping its progress and you are still very opinionated
on how I should be coding.

As the one that is actually writing this, the 3 line assembly I posted
is way easier to understand. Use assembly for new tests.

Cheeers,
Rafael


More information about the llvm-commits mailing list