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

[Jinyang He via Phabricator via llvm-commits]

MQ-mengqing added inline comments.


================
Comment at: lld/ELF/InputSection.cpp:653
+    // duplicate some logic here.
+    if (sym.isTls()) {
+      if (sym.hasFlag(NEEDS_TLSGD))
----------------
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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138135