[llvm-commits] [Patch] Bugfix: Linker won't map the same named struct from the same context included in different modules

[arkaitzj at gmail.com]

Hi,
I filled a bug report here, although it might be working as designed:
http://llvm.org/bugs/show_bug.cgi?id=14609

Description:
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.

--
Arkaitz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121215/89ad7efe/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm.patch
Type: application/octet-stream
Size: 793 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121215/89ad7efe/attachment.obj>