[llvm-bugs] [Bug 48030] New: [ItaniumCXXABI] TLS variable access wrapper optimization causes initializer function alias to be undefined (0)

via llvm-bugs llvm-bugs at lists.llvm.org
Fri Oct 30 17:56:00 PDT 2020


https://bugs.llvm.org/show_bug.cgi?id=48030

            Bug ID: 48030
           Summary: [ItaniumCXXABI] TLS variable access wrapper
                    optimization causes initializer function alias to be
                    undefined (0)
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: Wolfgang_Pieb at playstation.sony.com
                CC: llvm-bugs at lists.llvm.org, neeilans at live.com,
                    richard-llvm at metafoo.co.uk

Created attachment 24116
  --> https://bugs.llvm.org/attachment.cgi?id=24116&action=edit
Test case

The following commit seems to have caused a serious issue wrt
the interaction of global initializers and the wrapper functions to
access thread-local variables:

commit 00223827a952f66e7426c9881a2a4229e59bb019
Author: Richard Smith <richard-llvm at metafoo.co.uk>
Date:   Thu Sep 12 20:00:24 2019 +0000

    Improve code generation for thread_local variables:

    Summary:
     * Don't bother using a thread wrapper when the variable is known to
       have constant initialization.
     * Emit the thread wrapper as discardable-if-unused in TUs that don't
       contain a definition of the thread_local variable.
     * Don't emit the thread wrapper at all if the thread_local variable
       is unused and discardable; it will be emitted by all TUs that need
       it.

    Reviewers: rjmccall, jdoerfert

    Subscribers: cfe-commits

    Tags: #clang

    Differential Revision: https://reviews.llvm.org/D67429

    llvm-svn: 371767

Given the code attached (in "a.h"), the compiler does not generate
a thread-local access wrapper function for the static member
TLS<S>::mData. It also does not generate a definition
for the variable's initializer function's alias. However, it still emits
the initializer function itself as part of a comdat group that encompasses
all sections needed for its initialization.

Given a second translation unit that does have a definition for the wrapper
function as well as a comdat group to contain the variable's initializer,
it is possible that the linker then picks the comdat group from the TU that
does not have the definition for the (weak) initializer function alias. In 
this case the call to the initializer function in the wrapper function can get
fixed up to call location 0, leading to a crash.

The attached source demonstrates the problem on Linux. The test either 
runs or crashes depending on the order of the files on the link line:

sh -x compile_and_run
+ CLANG=/home/test/build/llvm/git/mono-repo/llvm-RelWithDebInfo/bin/clang
+ /home/test/build/llvm/git/mono-repo/llvm-RelWithDebInfo/bin/clang -I.
main.cpp a.cpp -o test1
+ /home/test/build/llvm/git/mono-repo/llvm-RelWithDebInfo/bin/clang -I. a.cpp
main.cpp -o test2
+ ./test1
entering main
returning
+ ./test2
entering main
Segmentation fault (core dumped)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20201031/ddf92d4f/attachment.html>


More information about the llvm-bugs mailing list