[PATCH] D138135: [lld][ELF] Support LoongArch

[WÁNG Xuěruì via Phabricator via llvm-commits]

xen0n marked 3 inline comments as done.
xen0n added inline comments.


================
Comment at: lld/ELF/InputSection.cpp:653
+    // duplicate some logic here.
+    if (sym.isTls()) {
+      if (sym.hasFlag(NEEDS_TLSGD))
----------------
MQ-mengqing wrote:
> xen0n wrote:
> > MQ-mengqing wrote:
> > > xen0n wrote:
> > > > MQ-mengqing wrote:
> > > > > xen0n wrote:
> > > > > > MQ-mengqing wrote:
> > > > > > > How about the "la.tls.ie" and "la.tls.gd" do the same symbol?
> > > > > > > How about the "la.tls.ie" and "la.tls.gd" do the same symbol?
> > > > > > 
> > > > > > What do you mean by "do the same symbol" here? Maybe you can tell me in a bit of Chinese if it's easier to explain that way... for now honestly I can't understand. (If you do attach some Chinese phrase I'll take care of translating it.)
> > > > > Sorry for the ambiguity words. I just care about the follows things,
> > > > > ```
> > > > > la.tls.ie $r4, y
> > > > > la.tls.gd $r5, y
> > > > > 
> > > > > .section .tbss
> > > > > .globl y
> > > > > y:
> > > > > .word   0
> > > > > .size   y, 4
> > > > > ```
> > > > > It plays differently with gnu as-ld.
> > > > I've located the TLS IE offset logic in the BFD code (IE symbol = offset by 2 GOT entries) and tried to do the same in LLD, but unfortunately the output was broken so I have to revert most of it. Sadly I won't have enough time to investigate before end of year.
> > > Ping for not getting reply about here for a long time.
> > > 
> > > File: test.s
> > > ```
> > > la.tls.ie $r4, y
> > > la.tls.gd $r5, y
> > > 
> > > .section .tbss
> > > .globl y
> > > y:
> > > .word   0
> > > .size   y, 4
> > > ```
> > > 
> > > Pre-cmd: 
> > >      $ llvm-mc -filetype=obj --triple=loongarch64 test.s -o test.o
> > >      $ ld.lld test.o -shared -o test.lld
> > >      $ ld test.o -shared -o test.ld
> > > 
> > > Compare1:
> > >     $ readelf -Wr test.{ld, lld}
> > > ```
> > > test.ld:
> > > 0000000000008008  0000000300000007 R_LARCH_TLS_DTPMOD64   0000000000000000 y + 0
> > > 0000000000008010  0000000300000009 R_LARCH_TLS_DTPREL64   0000000000000000 y + 0
> > > 0000000000008018  000000030000000b R_LARCH_TLS_TPREL64    0000000000000000 y + 0
> > > 
> > > test.lld:
> > > 0000000000020398  0000000100000002 R_LARCH_64             0000000000000000 y + 0
> > > 00000000000203a0  0000000100000007 R_LARCH_TLS_DTPMOD64   0000000000000000 y + 0
> > > 00000000000203a8  0000000100000009 R_LARCH_TLS_DTPREL64   0000000000000000 y + 0
> > > 00000000000203b0  000000010000000b R_LARCH_TLS_TPREL64    0000000000000000 y + 0
> > > ```
> > > Compare2:
> > >     $ objdump -d test.{ld, lld}
> > > ```
> > > test.ld:
> > > 0000000000000250 <.text>:
> > >  250:	1a000104 	pcalau12i   	$a0, 8(0x8)
> > >  254:	28c06084 	ld.d        	$a0, $a0, 24(0x18)
> > >  258:	1a000105 	pcalau12i   	$a1, 8(0x8)
> > >  25c:	02c020a5 	addi.d      	$a1, $a1, 8(0x8)
> > > 
> > > test.lld:
> > > 00000000000102d0 <.text>:
> > >    102d0:	1a000204 	pcalau12i   	$a0, 16(0x10)
> > >    102d4:	28ce8084 	ld.d        	$a0, $a0, 928(0x3a0)
> > >    102d8:	1a000205 	pcalau12i   	$a1, 16(0x10)
> > >    102dc:	02ce80a5 	addi.d      	$a1, $a1, 928(0x3a0)
> > > ```
> > Actually I'm not sure if the behavior difference is mission-critical, as things fully work (or at least seems to) when I bootstrapped Gentoo with LLVM/Clang. Do you want me to take care of this before merging the whole thing?
> It not matters, it is hard to happen, maybe. It is a hidden danger
> and developers should notice something may wrong if that occurs.
> But, I also think it is not mission-critical. It can be documented and
> fixed later.
Okay, I'll soon add the test case but note the current behavioral difference so we can get to fix it later.

Sorry for not handling this as promptly as I'd like to; real life and other reasons kick in.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138135/new/

https://reviews.llvm.org/D138135