[lld] r271569 - Start adding tlsdesc support for aarch64.

[Renato Golin]

On 2 June 2016 at 20:49, Rafael Espindola via llvm-commits

Author: rafael
Date: Thu Jun 2 14:49:53 2016
New Revision: 271569
URL: http://llvm.org/viewvc/llvm-project?rev=271569&view=rev
Start adding tlsdesc support for aarch64.
This is mostly extracted from http://reviews.llvm.org/D18960.

Rafael,

Why commit part of Adhemerval's patch without reviewing his request?
This is a really serious breach of community trust.

Not only we're waiting for reviews on the TLS set of patches and
having to rebase every two weeks, but now you implemented in a way
that wasn't discussed on the review, didn't mention authorship, nor
asked Adhemerval for any input.

If you had technical input on his patch, you should have done on the
review. If you wanted him to split in smaller patches, you should have
asked on the review and let *him* do it.

Even if you were the code owner (which you're not), it would still be
a *serious* breach of trust and respect.

I hereby respectfully request that you revert your patch and let
Adhemerval finish the work that he started in the way that we normally
do in the LLVM community.

regards,
--renato

[Renato Golin]

Because the patch includes way too much and doesn't explain what it is doing.

So let me get this straight: someone publishes a patch, you don't like
it, you do some private investigations and commit whatever you want
without even notifying the original authors?

I don't know how you work at your company, but this is not how open
source development works.

This is not the first time either that you step over people's toes
with your "design decisions" that you don't share with anyone. Last
year, Adhemerval has worked for three months to get the LLD AArch64
back-end working and out of the blue, no warning, the whole back-end
was yanked.

It doesn't matter if it was the right decision or not in the long
term, we don't just yank things, especially not before some
deliberation on the list. See how long is taking for the new pass
manager to be enabled, or FastIsel or the new Selection, or the new
register allocators, etc.

That's not how open source works and I assumed you knew that.

That is a general problem with aarch64, the documentation is missing
and comments have to make due. I had a lot of work to rewrite the
original aarch64 patches to be in line with the rest of lld and I
didn't want to have to do the same for tls.

You shouldn't be rewriting *any* patch, but asking the original
authors to do that themselves.

There is a pattern that I'm seeing and that's that *you* refuse or
dismiss more patches than most other people. There are many of your
comments on reviews that are just personal, and then you step over
people's toes and commits yourself.

This does not scale. But more importantly, it puts into doubt the
validity of the tool you're so hardly defending.

You see, 3 years ago, I was asked to choose between MCLinker and LLD.
MCLinker was a linker for all purposes, but Chris Lattner convinced me
that LLD is the LLVM linker, and we should be focusing all efforts
there.

It goes against the commercial interests of Linaro members to choose
such a premature technology, and it did put them back years of
development, because MCLinker was very close to ready, and MediaTek,
despite what people said, was very willing to accept our help.

But in the interest of the community, and the open source nature of my
work, I have decided to pursue LLD and managed to convince Linaro to
put two people working on it. But now, I'm re-evaluating all my
strategy, and sincerely, I do not trust the LLD community anymore.

The delay was because of the above mentioned issues. I wanted to make
sure there was a solid foundation.

Some patches are quick to review, others take 6 months. If you work in
open source you have *got* to understand that. If you're not willing
to take that cost, than please, refrain from working open source.

Sorry, no.

I understand your position, but you have to understand mine. I
therefore call into question your ability to care about such an
important project of the LLVM community.

I sincerely believe that your actions are harming the project, and the
people trying to help. I appreciate the value of your contribution, I
really do, but if you don't change your way to handle open source
contributions, LLD will, whether you like it or not, become irrelevant
and be replaced.

Such is the nature of open source.

cheers,
--renato

[Rui Ueyama]

Because the patch includes way too much and doesn't explain what it is

doing.
So let me get this straight: someone publishes a patch, you don't like
it, you do some private investigations and commit whatever you want
without even notifying the original authors?
I don't know how you work at your company, but this is not how open
source development works.
This is not the first time either that you step over people's toes
with your "design decisions" that you don't share with anyone. Last
year, Adhemerval has worked for three months to get the LLD AArch64
back-end working and out of the blue, no warning, the whole back-end
was yanked.
It doesn't matter if it was the right decision or not in the long
term, we don't just yank things, especially not before some
deliberation on the list. See how long is taking for the new pass
manager to be enabled, or FastIsel or the new Selection, or the new
register allocators, etc.
That's not how open source works and I assumed you knew that.

That is a general problem with aarch64, the documentation is missing
and comments have to make due. I had a lot of work to rewrite the
original aarch64 patches to be in line with the rest of lld and I
didn't want to have to do the same for tls.

You shouldn't be rewriting *any* patch, but asking the original
authors to do that themselves.
There is a pattern that I'm seeing and that's that *you* refuse or
dismiss more patches than most other people. There are many of your
comments on reviews that are just personal, and then you step over
people's toes and commits yourself.
This does not scale. But more importantly, it puts into doubt the
validity of the tool you're so hardly defending.
You see, 3 years ago, I was asked to choose between MCLinker and LLD.
MCLinker was a linker for all purposes, but Chris Lattner convinced me
that LLD is the LLVM linker, and we should be focusing all efforts
there.
It goes against the commercial interests of Linaro members to choose
such a premature technology, and it did put them back years of
development, because MCLinker was very close to ready, and MediaTek,
despite what people said, was very willing to accept our help.
But in the interest of the community, and the open source nature of my
work, I have decided to pursue LLD and managed to convince Linaro to
put two people working on it. But now, I'm re-evaluating all my
strategy, and sincerely, I do not trust the LLD community anymore.

Not so fast to conclude that the community is not trustworthy, it doesn't
consist of a single person or a single action. I do appreciate all
developers who contribute to the project and want to foster the cooperative
environment. As to the technical point, I honestly don't fully understand
the particular patches in every detail, and since Rafael rewrote that part
of code recently, I trust him that he is the most knowledgeable person who
can make a best technical decision.

Being said that, for this particular instance, I wouldn't submit right away
but send it to review and explain why I think better. I'm totally fine if
someone who knows more than me write a better patch than mine as a result
of code review for my patch, but I would be surprised if an alternative is
just submitted. I'm not sure if this needs to be reverted, but at least,
could you send it review next time in a similar situation, Rafael?

The delay was because of the above mentioned issues. I wanted to make

sure there was a solid foundation.

Some patches are quick to review, others take 6 months. If you work in
open source you have *got* to understand that. If you're not willing
to take that cost, than please, refrain from working open source.

Sorry, no.

I understand your position, but you have to understand mine. I
therefore call into question your ability to care about such an
important project of the LLVM community.
I sincerely believe that your actions are harming the project, and the
people trying to help. I appreciate the value of your contribution, I
really do, but if you don't change your way to handle open source
contributions, LLD will, whether you like it or not, become irrelevant
and be replaced.
Such is the nature of open source.
cheers,
--renato

[Renato Golin]

Post by Rui Ueyama
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

[Renato Golin]

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

[Rui Ueyama]

Post by Renato Golin

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.

Renato, it is not appropriate to call it my and Rafael's pet project. First
of all, Rafael and me are working on it for different purposes and probably
have different visions (although our taste on good code and good design
seems similar.) I'm interested in using it in my company and on FreeBSD,
for example. Rafael and I have no side channel to communicate, and we are
just collaborating openly on this mailing list.

You overlooked a lot of contributions that has been made to LLD. George
designed and wrote a great deal of relocation handling code and TLS
optimizations besides other contributions. Peter came up with a different
symbol table design, sent a proposal to the mailing list for discussion,
and implemented it (even though Peter and I are working for the same
company, that was not a coordinated effort, and the design change proposal
was out of the blue to me. I was surprised by his improvement.) Simon
implemented all of MIPS code that's pretty tricky. Davide is contributing
to AArch64 and LTO. There are many more contributors. I'm truly respectful
to all the contributors, and attributing these efforts to someone's pet
project is honestly a bit insulting.

I have never declined contributions by saying that "I know better." I
requested design documents (because I don't know better!) when contributors
seem to be starting large design changes, but that was needed for
discussion. If you want to do some large change, you want to convince other
collaborators that your design will work. It is I think a usual process.

Needless to say, I don't think I (and Rafael) should get a special
treatment. Both do not have right to submit without convincing other
collaborators. For example, just last week, I sent a patch which I truly
believed non-controversial and good one for review, and got rejected
unexpectedly by Sean. I had to convince him. That's how it works.

I sincerely request you to retract your recommendation to not collaborate
with us.

I'm not protecting what Rafael did. Rafael, even if you think your patch
had less common with the patch that's under review, they overlapped each
other with a great deal. Reviewing one patch and submitting a conflicting
one at the same time is not an appropriate behavior, and I do understand
why it disappointed Adhemerval and Renato. You needed to send it to review
and explain yours if you believe yours is different and better.

Post by Renato Golin
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?

I cannot say about every developer, but at least to me, my answer is yes,
of course.

Rui, Nick, Chris?

Post by Renato Golin
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.

[Rui Ueyama]

Post by Rui Ueyama

Post by Renato Golin

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.

Renato, it is not appropriate to call it my and Rafael's pet project.
First of all, Rafael and me are working on it for different purposes and
probably have different visions (although our taste on good code and good
design seems similar.) I'm interested in using it in my company and on
FreeBSD, for example. Rafael and I have no side channel to communicate, and
we are just collaborating openly on this mailing list.
You overlooked a lot of contributions that has been made to LLD. George
designed and wrote a great deal of relocation handling code and TLS
optimizations besides other contributions. Peter came up with a different
symbol table design, sent a proposal to the mailing list for discussion,
and implemented it (even though Peter and I are working for the same
company, that was not a coordinated effort, and the design change proposal
was out of the blue to me. I was surprised by his improvement.) Simon
implemented all of MIPS code that's pretty tricky. Davide is contributing
to AArch64 and LTO. There are many more contributors. I'm truly respectful
to all the contributors, and attributing these efforts to someone's pet
project is honestly a bit insulting.
I have never declined contributions by saying that "I know better." I
requested design documents (because I don't know better!) when contributors
seem to be starting large design changes, but that was needed for
discussion. If you want to do some large change, you want to convince other
collaborators that your design will work. It is I think a usual process.
Needless to say, I don't think I (and Rafael) should get a special
treatment. Both do not have right to submit without convincing other
collaborators. For example, just last week, I sent a patch which I truly
believed non-controversial and good one for review, and got rejected
unexpectedly by Sean. I had to convince him. That's how it works.
I sincerely request you to retract your recommendation to not collaborate
with us.
I'm not protecting what Rafael did. Rafael, even if you think your patch
had less common with the patch that's under review, they overlapped each
other with a great deal. Reviewing one patch and submitting a conflicting
one at the same time is not an appropriate behavior, and I do understand
why it disappointed Adhemerval and Renato. You needed to send it to review
and explain yours if you believe yours is different and better.

Post by Renato Golin
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?

I cannot say about every developer, but at least to me, my answer is yes,
of course.

Oh, wait! I may have been misread the sentence. I read "write better code
in LLD to replace existing part of LLD". I had totally no intention to say
that you should try something outside LLD. I'm sorry for the confusion.

Rui, Nick, Chris?

Post by Rui Ueyama

Post by Renato Golin
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.

[Renato Golin]

Post by Rui Ueyama
Renato, it is not appropriate to call it my and Rafael's pet project.

Hi Rui,

I apologise, that was wrong in all levels.

I know how much other people have contributed, but these people are on
the inside already, so their contributions are more easily accepted.

We have been trying to contribute for more than a year and have yet
failed to get in the loop. We were asked to wait for 2 years until the
core linker was ready, we did. Last year we wasted 3 months on the old
back end, and were told to wait again. Now we wasted another 4 months
this year, and all we did was re-written without warning. I cannot
recommend Linaro to continue wasting any more time.

Post by Rui Ueyama
I have never declined contributions by saying that "I know better." I
requested design documents (because I don't know better!) when contributors
seem to be starting large design changes, but that was needed for
discussion. If you want to do some large change, you want to convince other
collaborators that your design will work. It is I think a usual process.

Again, I apologise. Your behaviour is by no means comparable to Rafael's.

But he's taking the stance and speaking for the LLD community, at
least that's what it looks like to me.

Linaro is not a drive-by contributor to LLVM, or even to LLD. And if
even long time contributors to LLVM, and professional developers with
decades of experience in linker technology, are getting this
treatment, what does that say about others?

Post by Rui Ueyama
I sincerely request you to retract your recommendation to not collaborate
with us.

Those are based on facts. Not about you, but about interacting the the
LLD community, which unfortunately, you're part of.

I don't want to blame people, I want to produce software, and the LLD
community is blocking our progress for 3 years already.

Post by Rui Ueyama
I had totally no intention to say that you should try something outside LLD. I'm sorry for the confusion.

That's what I meant, yes. :)

Let me re-write my question to make sure we get over the language barrier:

Is the LLD community in agreement that a few core developers can and
will continue to block contributions, while doing all the work
themselves until such a day that it's deemed ready by the same
developers, in which time that everyone else will then, be allowed to
collaborate?

Or is the community in disagreement with Rafael's behaviour and will
try to not only curb it, but openly and actively promote more
collaboration by allowing other people to participate in the design
and implementation of their own targets?

If the former, than I'll respectfully move to MCLinker. If the latter,
than I expect due process and future collaborations, including letting
Adhemerval complete the AArch64 TLS implementation with proper code
review, not bypass re-writes.

As I said earlier, we'll continue to collaborate on LLD for the time
being on both ARM and AArch64 targets, and the next months will be a
test of how the LLD community will respond to this incident.

Peter Smith has just sent an initial implementation for the ARM target
(D20951), and he's working on improving it to be able to self-host
Clang on ARM in the next few months. I seriously hope that this
doesn't end up as another bad decision.

cheers,
--renato

[Rui Ueyama]

Post by Renato Golin

Post by Rui Ueyama
Renato, it is not appropriate to call it my and Rafael's pet project.

Hi Rui,
I apologise, that was wrong in all levels.
I know how much other people have contributed, but these people are on
the inside already, so their contributions are more easily accepted.
We have been trying to contribute for more than a year and have yet
failed to get in the loop. We were asked to wait for 2 years until the
core linker was ready, we did. Last year we wasted 3 months on the old
back end, and were told to wait again. Now we wasted another 4 months
this year, and all we did was re-written without warning. I cannot
recommend Linaro to continue wasting any more time.

Post by Rui Ueyama
I have never declined contributions by saying that "I know better." I
requested design documents (because I don't know better!) when

contributors

Post by Rui Ueyama
seem to be starting large design changes, but that was needed for
discussion. If you want to do some large change, you want to convince

other

Post by Rui Ueyama
collaborators that your design will work. It is I think a usual process.

Again, I apologise. Your behaviour is by no means comparable to Rafael's.
But he's taking the stance and speaking for the LLD community, at
least that's what it looks like to me.
Linaro is not a drive-by contributor to LLVM, or even to LLD. And if
even long time contributors to LLVM, and professional developers with
decades of experience in linker technology, are getting this
treatment, what does that say about others?

Post by Rui Ueyama
I sincerely request you to retract your recommendation to not collaborate
with us.

Those are based on facts. Not about you, but about interacting the the
LLD community, which unfortunately, you're part of.
I don't want to blame people, I want to produce software, and the LLD
community is blocking our progress for 3 years already.

Post by Rui Ueyama
I had totally no intention to say that you should try something outside

LLD. I'm sorry for the confusion.
That's what I meant, yes. :)
Is the LLD community in agreement that a few core developers can and
will continue to block contributions, while doing all the work
themselves until such a day that it's deemed ready by the same
developers, in which time that everyone else will then, be allowed to
collaborate?

No, and I think I've never blocked any contributions for such reason. I
apologize I didn't review Adhemerval patch. My knowledge of AArch64 and TLS
optimizations is limited, and since Rafael (who knows most about relocation
handling in LLD) was reviewing it, I deferred it to him. I'll try to review
it next time.

Post by Renato Golin
Or is the community in disagreement with Rafael's behaviour and will
try to not only curb it, but openly and actively promote more
collaboration by allowing other people to participate in the design
and implementation of their own targets?

Yes, including the part that Rafael should have done this differently.

Rafael, I think you want to slow down a little bit and take more time on
getting consensus on commits, even for things that you think "too obvious".
Code review for LLD is usually fast, and overall it would make the
development even faster because of smooth communication between
collaborators.

Post by Renato Golin
If the former, than I'll respectfully move to MCLinker. If the latter,
than I expect due process and future collaborations, including letting
Adhemerval complete the AArch64 TLS implementation with proper code
review, not bypass re-writes.
As I said earlier, we'll continue to collaborate on LLD for the time
being on both ARM and AArch64 targets, and the next months will be a
test of how the LLD community will respond to this incident.
Peter Smith has just sent an initial implementation for the ARM target
(D20951), and he's working on improving it to be able to self-host
Clang on ARM in the next few months. I seriously hope that this
doesn't end up as another bad decision.
cheers,
--renato

[Renato Golin]

Post by Rui Ueyama

Post by Renato Golin
Is the LLD community in agreement that a few core developers can and
will continue to block contributions, while doing all the work
themselves until such a day that it's deemed ready by the same
developers, in which time that everyone else will then, be allowed to
collaborate?

No, and I think I've never blocked any contributions for such reason. I
apologize I didn't review Adhemerval patch. My knowledge of AArch64 and TLS
optimizations is limited, and since Rafael (who knows most about relocation
handling in LLD) was reviewing it, I deferred it to him. I'll try to review
it next time.

Post by Renato Golin
Or is the community in disagreement with Rafael's behaviour and will
try to not only curb it, but openly and actively promote more
collaboration by allowing other people to participate in the design
and implementation of their own targets?

Yes, including the part that Rafael should have done this differently.
Rafael, I think you want to slow down a little bit and take more time on
getting consensus on commits, even for things that you think "too obvious".
Code review for LLD is usually fast, and overall it would make the
development even faster because of smooth communication between
collaborators.

Rui,

Thank you very much for your response.

I'm relieved that I had not made the wrong decision about LLD some
years back, and I really appreciate the work you have being putting on
it.

Looking forward to more collaborations in the present and future!

cheers,
--renato