search for: tlsdesc

tl;dr: TLSDESC have solved most problems in formerly inefficient TLS access models, so I think we can drop TLS relaxation support from lld. lld's code to handle relocations is a mess; the code consists of a lot of cascading "if"s and needs a lot of prior knowledge to understand what it is doing. Ho...

On Tue, Nov 7, 2017 at 6:59 PM, Rafael Avila de Espindola < rafael.espindola at gmail.com> wrote: > Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > tl;dr: TLSDESC have solved most problems in formerly inefficient TLS > access > > models, so I think we can drop TLS relaxation support from lld. > > > > lld's code to handle relocations is a mess; the code consists of a lot of > > cascading "if"s and needs a lot of prior...

On Tue, Nov 7, 2017 at 8:16 PM, Rafael Avila de Espindola < rafael.espindola at gmail.com> wrote: > Rui Ueyama <ruiu at google.com> writes: > > >> So I am strongly against removing either non TLSDESC support of support > >> for the relaxations. > >> > > > > It's still pretty arguable. By default, compilers use General Dynamic > model > > with -fpic, and Initial Exec without -fpic. > > It is more complicated than that. You can get all 4 modes with...

...ed the > > patches without thinking hard enough, but I didn't see a convincing > > benchmark result (or even a non-convincing one) that shows that these > > relaxations actually make real-world programs faster. Do you know of > > any? It is funny that even the creator of TLSDESC found that their > > optimization didn't actually makes NPTL faster as it is mentioned in the > > "Conclusion" section in http://www.fsfla.org/~lxoliva/ > > writeups/TLS/RFC-TLSDESC-x86.txt. > > > > So I don't think I'm proposing we simplify code...

On 2 June 2016 at 20:49, Rafael Espindola via llvm-commits <llvm-commits at lists.llvm.org> wrote: > Author: rafael > Date: Thu Jun 2 14:49:53 2016 > New Revision: 271569 > > URL: http://llvm.org/viewvc/llvm-project?rev=271569&view=rev > Log: > 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 h...

On 3 June 2016 at 18:47, Rui Ueyama <ruiu at google.com> 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

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

On 2 June 2016 at 23:22, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > 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

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

I'd like to convert the following call A at GDPLT //R_HEX_GD_PLT_B22_PCREL to call __tls_get_addr //R_HEX_B22_PCREL "A" is a TLS variable and preceding code has prepared for the call. When the R_HEX_GD_PLT_B22_PCREL is found it will initially point to the TLS variable so at that point I'd like to define a __tls_get_addr symbol and update the relocation's type and symbol

Hi, Some time ago there were some information about aarch64 support for the lld linker project: http://lld.llvm.org/open_projects.html#elf-aarch64 Right now there is no such information. Also there is some presentation described that the simple application can be linked using lld: http://llvm.org/devmtg/2016-03/Presentations/EuroLLVM%202016-%20New%20LLD%20linker%20for%20ELF.pdf What is the

...olin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Dima, > > Adhemerval is working on AArch64 support, and it should be mostly > there, though some missing TLS support. He should know more. Here's some info on TLS. Review D18960 has the initial implementation for TLSDESC support: http://reviews.llvm.org/D18960 I've been occasionally testing FreeBSD/arm64 buildworld with lld and managed to get everything to link with an earlier version of D18960 and an equivalent set of workarounds as on FreeBSD/amd64. There is some TLS bug outstanding that caused all binaries...