llvm dev - Jun 2016 - [lld] r271569 - Start adding tlsdesc support for aarch64.

On 3 June 2016 at 01:53, Rui Ueyama <ruiu at google.com>
wrote:
> Not so fast to conclude that the community is not trustworthy, it
doesn't
> consist of a single person or a single action.
This is not an isolated incident. This seems to be the general
behaviour around LLD, which is less so in the rest of the LLVM
projects.

The obliteration of the old ELF back-end was discussed only between a
few people, not on the list. The technical reasoning could have been
solid for a new back-end, but not for destroying fresh code. The
removal was weeks after Adhemerval had LLD bootstrapping Clang on
AArch64 upstream.

There were backlashes to that decision, as well as other decisions in
this list, and many people have already demonstrated discontent with
how LLD patches and decisions are handled.

During EuroLLVM's LLD presentation, a lot of people asked technical
questions about the implementation of wanted features like library
order, linker scripts, version scripts, and all answers were "it's not
that hard, it's all in my head, don't worry about it".

If this was a closed source project, and you, Rafael, Nick and PCC
were the team developing it, it'd be expected that the team lead would
have some leeway on the implementation and the consumers would have to
wait until it's ready. But this is open source, and that's absolutely
*not* how things work out here. That is *precisely* the problem, not
this one incident. This incident was just the tipping point.

That is why I personally don't trust the LLD community to act in the
open source way. I have seen it consistently repeated over the last
two years that I'm following. It makes no difference if this is a new
project or not, this is open source, and in open source we work
collaboratively. If you refuse people's patches because "you know
better", you're not doing open source and people doing it will move
elsewhere. This is not about you, me or Rafael, this is about the LLVM
linker.

So, I'll now be going back looking at MCLinker and see if we can make
a Linux/BSD ARM/AArch64 upstream linker out of it, compatible with the
GNU environment. As you can see [1], the development is still active,
up-to-date with modern LLVM and there are ARM and MIPS support
already, and the community there is far more receptive than LLD's.

We'll continue to work on ARM and AArch64 patches to LLD, but if
MCLinker proves an easier route to achieve our final goal, which is to
have a Lesser-licensed open source ARM/AArch64 linker for GNU/BSD
environments, and LLD's community continues to offer resistance and
bad behaviour, we'll slowly de-phase LLD in favour of MCLinker, at
least at Linaro.

Such is the nature of open source.

cheers,
--renato

[1] https://github.com/mclinker/mclinker

> This is not an isolated incident. This seems to be the general
> behaviour around LLD, which is less so in the rest of the LLVM
> projects.
Do keep in mind you are comparing a 11 year old project and a 11 month
old one. There is a lot more churn on the 11 month old one.
> The obliteration of the old ELF back-end was discussed only between a
> few people, not on the list. The technical reasoning could have been
> solid for a new back-end, but not for destroying fresh code. The
> removal was weeks after Adhemerval had LLD bootstrapping Clang on
> AArch64 upstream.
Again, I am truly sorry we were unable to come up with a perfect
design the first time. For the record, I don't think it is perfect
yet. There will likely be more big changes to lld. That is the cost of
trying to build as good a linker as we can.

If you thing the old one is better, feel free to try to make it work
better than the current one. It will always be available on svn
history.
> There were backlashes to that decision, as well as other decisions in
> this list, and many people have already demonstrated discontent with
> how LLD patches and decisions are handled.
>
> During EuroLLVM's LLD presentation, a lot of people asked technical
> questions about the implementation of wanted features like library
> order, linker scripts, version scripts, and all answers were "it's
not
> that hard, it's all in my head, don't worry about it".

Being open source doesn't mean I get to implement what someone else
wants. You are more than welcome to send patches, but they have avoid
harming the rest of the linker. In particular, at this early stage
they cannot harm its development. Once we have a mature project we can
actually evaluate tradeoff.

And just like we did, you are more than welcome to try to write
something better. Please let us know how it goes.

Cheers,
Rafael

On 3 June 2016 at 17:10, Rafael Espíndola <rafael.espindola at gmail.com>
wrote:
> Do keep in mind you are comparing a 11 year old project and a 11 month
> old one. There is a lot more churn on the 11 month old one.
LLD is at least 5 years old. Every time you re-write it doesn't reset
history.

> Again, I am truly sorry we were unable to come up with a perfect
> design the first time. For the record, I don't think it is perfect
> yet. There will likely be more big changes to lld. That is the cost of
> trying to build as good a linker as we can.
This is not about what you do. It's about *how* you do it.

We have developers trying to create a linker. They are working on LLD
because Chris wanted a true LLVM linker. But it seems that you want a
project that you can do whatever you want, whenever you want.

This is *NOT* open source. Right now, LLD is *nothing more* than Rui's
and Rafael's pet project. I cannot recommend Linaro to collaborate on
those terms, and I sincerely recommend anyone that is listening to
this thread to not do so either.

> Being open source doesn't mean I get to implement what someone else
> wants. You are more than welcome to send patches, but they have avoid
> harming the rest of the linker. In particular, at this early stage
> they cannot harm its development. Once we have a mature project we can
> actually evaluate tradeoff.
We're clearly not welcome to send patches. We did, and you re-wrote it
and committed without asking the original author.

So, the plan is to wait for you to finish the initial implementation
alone? Again? What do we do in the interim? How many times are we
going to go through this?

I have waited 2 years before LLD was barely useful, then Adhemerval
implemented the AArch64 back-end. Then you destroyed and now we have
waited another year, but we're still unable to collaborate. If
anything, now it's even harder than it was last year.

Why can't we help with the design, too? We know about ARM and AArch64,
that's what we do, and we can provide you with the expertise without
having to go on your own doing everything. That is the whole point of
collaborative development, and it seems that you're missing this
point.

> And just like we did, you are more than welcome to try to write
> something better. Please let us know how it goes.
Is this the position of every LLD developer?

Rui, Nick, Chris?

I'm seriously looking for others to chime in and let me know if that
is the final stance on LLD, so that I can finally write it off and go
work on another linker.

If the official position is that LLD is a project that only Rui and
Rafael can design and implement for another 2~3 years, I *cannot*
recommend Linaro and its members to participate.

cheers,
--renato