[Mostly just giving some powerpc64 detail, at least when base/binutils is used.]
On 2018-Oct-22, at 2:35 PM, John Baldwin <jhb at freebsd.org> wrote: > On 10/19/18 7:23 AM, Mark Millard wrote: >> [I'm adding toolchain and John B. to the TO: list. John B. >> may want to reply to Sean F. I'm also adding a >> /lib/libgcc_s.so related item to the list of 3 known >> issues.] >> >>> On 2018-Oct-19, at 6:21 AM, Sean Fertile <sd.fertile at gmail.com> wrote: >>> >>> Clang isn't getting the tls model wrong, it actually generates pic code by >>> default as if -fpic were specified. I think the original intent behind >>> switching >>> to pic by default was due to incorrectly thinking gcc was pic by default >>> (I'm not sure if this was meant as only gcc on BSD or gcc on powerpc64 in >>> general), >>> as well as working around some problems that clangs non-pic codegen has/had >>> for the ELF V1 abi. There are some patches on phabricator for switching >>> the default back to non-pic codegen, but they leave the pic default for >>> BSD: https://reviews.llvm.org/D53384 and https://reviews.llvm.org/D53383 >>> >>> According to what you and John are saying the pic default is incorrect for >>> BSD as well. If thats the case please either comment on the reviews to let >>> Stefan know, >>> or let me know here and we can update the patches accordingly. > > No, what I am saying is that in GCC, the decision for dynamic TLS model > vs static TLS model is based on whether or not -fPIC is explicitly > given on the command line. For MIPS at least (where I am familiar with > this), both GCC and clang default to implicit PIC. FYI: John discovered that mips64/powerpc64 is the context for PIC being the default for clang (I'm ignoring x86_64, Windows, MachO and MacOSX in my comments): bool Generic_GCC::isPICDefault() const { switch (getArch()) { case llvm::Triple::x86_64: return getTriple().isOSWindows(); case llvm::Triple::ppc64: case llvm::Triple::ppc64le: return !getTriple().isOSBinFormatMachO() && !getTriple().isMacOSX(); case llvm::Triple::mips64: case llvm::Triple::mips64el: return true; default: return false; } } > However, GCC uses > static TLS models (initial-exec, etc.) when -fPIC isn't given on the > command line even if PIC is still implicitly enabled. It only uses the > dynamic TLS models (intended for use in shared libraries) if -fPIC is > explicitly passed on the command line. > However, clang implements implicit PIC by passing the equivalent of > -fPIC to the llvm backend, so on MIPS at least, the result is that llvm > _always_ uses the dynamic TLS models including for static libraries and > binaries where this is wrong. I have some patches from one of the LLVM > MIPS folks that kind of hackishly fix this, but by adding a new flag > only for MIPS. I wanted to adjust their patches to be more generic so > that there's a new '-mshared-library' or some such passed from clang > to llvm and have clang only set that to true if -fPIC is explicitly > given on the command line to match GCC's behavior. > > So to be clear, this isn't saying that the implicit PIC setting is > wrong. It is saying that the llvm backend incorrectly interprets > the clang front-end's implicit PIC setting as being an explicit PIC > setting for the purposes of choosing the TLS model to use. For powerpc64 things are somewhat different via some link-time optimizations when base/binutils is in use (lld not being ready for use for powerpc64 as I understand). (I've no clue what would happen with lld.) cc -g -O2 -c will produce .o files with the __tls_get_addr calls, for example (source shown later): # objdump -r tlsy.o | grep __tls_get_addr 0000000000000024 R_PPC64_REL24 __tls_get_addr 0000000000000038 R_PPC64_REL24 __tls_get_addr # objdump -r tls_main.o | grep __tls_get_addr 0000000000000020 R_PPC64_REL24 __tls_get_addr 0000000000000034 R_PPC64_REL24 __tls_get_addr 000000000000008c R_PPC64_REL24 __tls_get_addr 00000000000000a0 R_PPC64_REL24 __tls_get_addr This is as John indicated. But the likes of: # cc -g -O0 tls_main.o tlsy.o tls.o ends up with a.out having r13 use and no such subroutine calls to __tls_get_addr in x, y, or main. There are some nop instructions from where substitutions were made. It appears that mips64 does not have such a late-optimization in John's context: the __tls_get_addr use survives into a.out as I understand. The source for the example used above was: # more tls.c int __thread i = 3; int __thread j = 2; # more tlsy.c extern int __thread i; extern int __thread j; int y() { return i+j; } # more tls_main.c extern int __thread i; extern int __thread j; extern int y(); int x() { return i+j; } int main () { return x()-y(); } (So main got some inlining of x() in order for the tls_main.o to show 4 R_PPC64_REL24 uses for __tls_get_addr .) I have no clue if the late-optimization for powerpc64 covers all the cases where direct use of some static TLS model would be appropriate. I just know that, at least in some types of contexts, some calls to __tls_get_addr are eliminated at link time when base/binutils is in use. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______________________________________________ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
