[LLVMbugs] [Bug 14609] New: Linker won't map the same named struct from the same context included in different modules

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Fri Dec 14 08:36:06 PST 2012


http://llvm.org/bugs/show_bug.cgi?id=14609

             Bug #: 14609
           Summary: Linker won't map the same named struct from the same
                    context included in different modules
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Linker
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: arkaitzj at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9706
  --> http://llvm.org/bugs/attachment.cgi?id=9706
LinkModules.cpp patch for linking modules with the same context

The LinkModules.cpp link implementation assumes the 2 modules were built with a
completely different context.

To map a type from module B into module A it relies in the fact that when
merging contexts all structs in module B named like any in module A got renamed
to name.NUMBER, like struct_name.1

In my use case in the same compiler run, I create module A and while creating
module B I take types from module A like module_a->getTypeByName("struct_name")

This causes that when I link both modules as struct_name was never requested in
module B context it didn't participate in the merging, it was already there,
and because of that there is no struct_name.1
When LinkModules iterates structs on module A and module B it does not detect
the type to be mapped so it does not intrudce it in the TypeMap and on later
resolution the Linker creates a whole new named struct type and injects it
there.

I have assumed that 2 StructTypes with the same name and the same address are
the same type so I have created this patch that adds it into the TypeMap and
type mapping works as expected, adding it to the TypeMap will check isomorphism
as well so there is no apparent risk.

Before the patch I used to get types as:
%0 = type { i8*, i8* }
%core_string = type { i8*, i8* }

in the linked file, if I dumped the modules and used llvm-link it would work
perfectly because it would load each file in a different context.

With the patch I get the same result as using llvm-link on the separated
modules.
%core_string = type { i8*, i8* }



It could well be that this was always intended, but then the only alternative I
see in this case to steal struct types from the first module is to do deep
copies of them, and I haven't seen any helper methods for that in any case.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.



More information about the llvm-bugs mailing list