Re: [lld] r271569 - Start adding tlsdesc support for aarch64.
On 3 June 2016 at 01:53, Rui Ueyama 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 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 30 May-3 June 2016
== Progress == * Validation - trying to improve cleanup job such that they skip offline nodes - reviews * Backports - successful backport for our gcc-6 branch * GCC - regressions reports on trunk - preparing removal of neon-testgen.ml * Misc (conf-calls, meetings, emails, ) == Next == * Validation - prepare switch to docker for buildfarm job - cleanup * Backports * GCC - trunk monitoring - more on AdvSIMD intrinsics ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 30 May-3 June 2016
== Progress == * Remove exit-on-error flag from CodeGen tests [TCWG-604] [4/10] - This is a follow-up of TCWG-592: when changing the diag handler, some of the tests started to fail, so we had to add an exit-on-error flag to preserve the old behaviour until we can fix the tests. - Patch fixing the MIR tests (PR27770) - still in upstream review - Submitted another patch fixing two other BPF tests (PR27768/9) - committed upstream - Submitted a patch fixing one of the AMDGPU tests (PR27761) - in upstream review - Investigating the ARM test (PR27765) * Use git worktree in llvm helper scripts [TCWG-587] [4/10] - In review, hopefully we can wrap it up soon * Misc [2/10] - More LLVM backend education (MI level), ARM ARM etc == Plan == * Remove exit-on-error flag from CodeGen tests [TCWG-604] - Fix the ARM test * Use git worktree in llvm helper scripts [TCWG-587] - Fix a regression in the error-handling - Address review comments ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [lld] r271569 - Start adding tlsdesc support for aarch64.
On 3 June 2016 at 17:10, Rafael Espíndola 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 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 1st June - 3rd June 2016
== Progress == - Holiday Monday/Tuesday - Finished writing initial support for ARM in lld. Posted upstream as RFC, no comments so far. - Implemented, but not tested the static Thumb relocations present in the arm-linux-gnueabihf-gcc -- I'd forgotten how much I hated the Thumb 2 instruction encodings. == Plan == - Add tests for Thumb relocations - Start thinking about how interworking can be implemented in lld ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [lld] r271569 - Start adding tlsdesc support for aarch64.
On 3 June 2016 at 18:47, Rui Ueyama wrote: > 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. > 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? > 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. > 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 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [lld] r271569 - Start adding tlsdesc support for aarch64.
On 3 June 2016 at 21:02, Rui Ueyama wrote: >> 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. > >> >> 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 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
