[llvm-bugs] [Bug 48425] New: [CloneModule] Cloned module retains some pointers to original module's objects

via llvm-bugs llvm-bugs at lists.llvm.org
Mon Dec 7 02:51:17 PST 2020


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

            Bug ID: 48425
           Summary: [CloneModule] Cloned module retains some pointers to
                    original module's objects
           Product: libraries
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Transformation Utilities
          Assignee: unassignedbugs at nondot.org
          Reporter: itay.bookstein at nextsilicon.com
                CC: llvm-bugs at lists.llvm.org

When BlockAddresses are used as initializers of GlobalVariables,
and the module is cloned, the BlockAddress constants used as
initializers in the cloned module contain pointers to the
BasicBlocks of the old module rather than the new one.

As far as I can tell, in ValueMapper.cpp, Mapper::flush() attempts
to RAUW the temporary basic block it created when attempting to map
the BlockAddress constant which it encountered as the initializer of
a GlobalVariable, and it passes the OldBB when failing to find a
target. To my limited understanding, it sounds risky/incorrect to
fall-back to the OldBB there. The BasicBlocks themselves are of
course properly mapped/cloned into the new module in CloneFunction.cpp,
in function llvm::CloneFunctionInto, but a comment there seems to
talk exactly about it not being legal to clone a function that has
an external BlockAddress referencing it.

-- 
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/20201207/bc2f2414/attachment.html>


More information about the llvm-bugs mailing list