[PATCH] D138135: [lld][ELF] Support LoongArch
Jinyang He via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Apr 3 00:37:55 PDT 2023
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
More information about the llvm-commits
mailing list