[llvm-bugs] [Bug 52133] New: duplicate symbol when loading the same framework via macho::parseLCLinkerOption

[via llvm-bugs]

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

            Bug ID: 52133
           Summary: duplicate symbol when loading the same framework via
                    macho::parseLCLinkerOption
           Product: lld
           Version: unspecified
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: MachO
          Assignee: unassignedbugs at nondot.org
          Reporter: zhongkaining.paxos at bytedance.com
                CC: gkm at fb.com, jezreel at gmail.com,
                    llvm-bugs at lists.llvm.org, smeenai at fb.com

Created attachment 25347
  --> https://bugs.llvm.org/attachment.cgi?id=25347&action=edit
As this screenshot shows, the two StringRef instances were supposed to be equal
(and they are equal at least before the string data of RHS was released)

When loading a framework twice from two object file via
macho::parseLCLinkerOption, loadedArchives is not aware that this framework was
already loaded, and thus report "error: duplicate symbol".

My guess is that this is because when lld was loading this framework for the
first time, the string representing the path of the framework was released when
lld exits from macho::parseLCLinkerOption, so the StringRef instance
representing this framework in DenseMap's bucket becomes an empty string
instead of the path of the framework. Therefore, when lld was trying to load
this framework for the second time, it finds the bucket for the same key
representing the path of the framework, only to find that the key in the bucket
is no longer equal to the key used to look up now, because the data in
StringRef instance was already released.

In line 631 in DenseMap.h, it tries to compare two StringRef instance to see if
they are equal by compare their data. However, since the data of the StringRef
instance stored in the bucket was released, this comparison function will
return false, thus causing loadedArchives cannot recognize that this framework
was already loaded.

I assume this can be solved by letting the bucket in DenseMap own the string
instance using std::string instead of llvm::StringRef, but this could costs
lots of space since the string instance is much larger than StringRef. Any
advice on this so I can fix this issue?

-- 
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/20211011/7233acf8/attachment.html>