Bug#890401: llvm-toolchain-4.0: Please include patch to fix code generation on sparc64

2018-02-14 Thread Sylvestre Ledru
On 14/02/2018 13:23, John Paul Adrian Glaubitz wrote:
> On 02/14/2018 01:22 PM, Sylvestre Ledru wrote:
>>> Which repository?
>> https://anonscm.debian.org/viewvc/pkg-llvm/llvm-toolchain/branches/
> 
> I didn't know I have commit access to this repository, do I?

You are now :)

(sorry for svn btw)

Sylvestre



Bug#890401: llvm-toolchain-4.0: Please include patch to fix code generation on sparc64

2018-02-14 Thread John Paul Adrian Glaubitz

On 02/14/2018 01:16 PM, Sylvestre Ledru wrote:

Could you please commit directly this change in the repo?


Which repository?

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



Bug#890401: llvm-toolchain-4.0: Please include patch to fix code generation on sparc64

2018-02-14 Thread John Paul Adrian Glaubitz

On 02/14/2018 01:22 PM, Sylvestre Ledru wrote:

Which repository?

https://anonscm.debian.org/viewvc/pkg-llvm/llvm-toolchain/branches/


I didn't know I have commit access to this repository, do I?

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



Bug#890401: llvm-toolchain-4.0: Please include patch to fix code generation on sparc64

2018-02-14 Thread Sylvestre Ledru
On 14/02/2018 13:20, John Paul Adrian Glaubitz wrote:
> On 02/14/2018 01:16 PM, Sylvestre Ledru wrote:
>> Could you please commit directly this change in the repo?
> 
> Which repository?
https://anonscm.debian.org/viewvc/pkg-llvm/llvm-toolchain/branches/

Sylvestre



Bug#890401: llvm-toolchain-4.0: Please include patch to fix code generation on sparc64

2018-02-14 Thread Sylvestre Ledru
Hello,

On 14/02/2018 13:11, John Paul Adrian Glaubitz wrote:
> Source: llvm-toolchain-4.0
> Version: 1:4.0.1-10
> Severity: normal
> Tags: patch
> User: debian-sp...@lists.debian.org
> Usertags: sparc64
> 
> Hello!
> 
> In order to get the Rust compiler work on sparc64, we need another
> LLVM patch which is currently being upstreamed [1] which fixes the
> code generation on sparc64.
> 
> Without the patch, LLVM generates invalid code that binutils stumbles
> over and crashes with an internal error [2]. With the patch merged,
> LLVM is working properly and allows a full native build of the Rust
> compiler on sparc64 :).
> 
> Since Rust upstream is currently still on LLVM 4.0, even for Rust
> 1.24, it would be nice to have the patch merged for the 4.0 version
> as well as the 6.0 version of the llvm-toolchain package. Although
> we are going to convince upstream to backport the patch for 6.0.
> Could you please commit directly this change in the repo?

Thanks,
Sylvestre



Bug#890401: llvm-toolchain-4.0: Please include patch to fix code generation on sparc64

2018-02-14 Thread John Paul Adrian Glaubitz
Source: llvm-toolchain-4.0
Version: 1:4.0.1-10
Severity: normal
Tags: patch
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hello!

In order to get the Rust compiler work on sparc64, we need another
LLVM patch which is currently being upstreamed [1] which fixes the
code generation on sparc64.

Without the patch, LLVM generates invalid code that binutils stumbles
over and crashes with an internal error [2]. With the patch merged,
LLVM is working properly and allows a full native build of the Rust
compiler on sparc64 :).

Since Rust upstream is currently still on LLVM 4.0, even for Rust
1.24, it would be nice to have the patch merged for the 4.0 version
as well as the 6.0 version of the llvm-toolchain package. Although
we are going to convince upstream to backport the patch for 6.0.

Thanks,
Adrian

> [1] https://reviews.llvm.org/D43271
> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=22832

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Description: [Sparc] Include __tls_get_addr in symbol table for TLS calls to it
 Global Dynamic and Local Dynamic call relocations only implicitly
 reference __tls_get_addr, but it still needs to be in the symbol table
 to be bound at link time otherwise it fails to link. For details, see
 https://sourceware.org/bugzilla/show_bug.cgi?id=22832.
Author: James Clarke 
Last-Update: 2018-02-14

--- llvm-toolchain-4.0-4.0.1.orig/lib/Target/Sparc/MCTargetDesc/SparcMCExpr.cpp
+++ llvm-toolchain-4.0-4.0.1/lib/Target/Sparc/MCTargetDesc/SparcMCExpr.cpp
@@ -194,14 +194,30 @@ static void fixELFSymbolsInTLSFixupsImpl
 void SparcMCExpr::fixELFSymbolsInTLSFixups(MCAssembler ) const {
   switch(getKind()) {
   default: return;
+  case VK_Sparc_TLS_GD_CALL:
+  case VK_Sparc_TLS_LDM_CALL: {
+// The corresponding relocations reference __tls_get_addr, as they call it,
+// but this is only implicit; there is no connection in the ELF file
+// between the relocation and the symbol, other than the specification for
+// the semantics of the relocations. However, the symbol must be included
+// in our symbol table despite the lack of references to it, since it needs
+// to be bound during linking for these relocations. For details see
+// https://sourceware.org/bugzilla/show_bug.cgi?id=22832.
+MCSymbol *Symbol = Asm.getContext().getOrCreateSymbol("__tls_get_addr");
+Asm.registerSymbol(*Symbol);
+auto ELFSymbol = cast(Symbol);
+if (!ELFSymbol->isBindingSet()) {
+  ELFSymbol->setBinding(ELF::STB_GLOBAL);
+  ELFSymbol->setExternal(true);
+}
+LLVM_FALLTHROUGH;
+  }
   case VK_Sparc_TLS_GD_HI22:
   case VK_Sparc_TLS_GD_LO10:
   case VK_Sparc_TLS_GD_ADD:
-  case VK_Sparc_TLS_GD_CALL:
   case VK_Sparc_TLS_LDM_HI22:
   case VK_Sparc_TLS_LDM_LO10:
   case VK_Sparc_TLS_LDM_ADD:
-  case VK_Sparc_TLS_LDM_CALL:
   case VK_Sparc_TLS_LDO_HIX22:
   case VK_Sparc_TLS_LDO_LOX10:
   case VK_Sparc_TLS_LDO_ADD: