metadata linking bug or by design

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

metadata linking bug or by design

Xi Wang
Hi,

It seems that current linker "drops" updated llvm::Value * references
in metadata.  Here goes an example.  We have a two-line source file
a.c:

static int x;
void foo() { x = 1; }

and a similar b.c:

static int x;
void bar() { x = 1; }

They both have an internal variable x; one of them will be renamed (to
x1) during linking.

clang -emit-llvm -c -g a.c
clang -emit-llvm -c -g b.c
llvm-link -o t.bc a.o b.o

Before linking we can see the following lines in both bitcode files
from a.c and b.c, where the last element of !5 refers to the internal
variable x.

!llvm.dbg.sp = !{!1}
!5 = metadata !{i32 655412, i32 0, metadata !0, metadata !"x",
metadata !"x", metadata !"", metadata !2, i32 1, metadata !6, i32 1,
i32 1, i32* @x} ; [ DW_TAG_variable ]

However after linking the last element of !11 becomes null.  I was
expecting that it would refer to the renamed x1.

!llvm.dbg.gv = !{!9, !11}
!9 = metadata !{i32 655412, i32 0, metadata !0, metadata !"x",
metadata !"x", metadata !"", metadata !3, i32 1, metadata !10, i32 1,
i32 1, i32* @x} ; [ DW_TAG_variable ]
!11 = metadata !{i32 655412, i32 0, metadata !1, metadata !"x",
metadata !"x", metadata !"", metadata !7, i32 1, metadata !12, i32 1,
i32 1, null} ; [ DW_TAG_variable ]

Is it intentional or a bug?  Thanks.

- xi
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: metadata linking bug or by design

Devang Patel

On Aug 4, 2011, at 8:21 AM, Xi Wang wrote:

> Hi,
>
> It seems that current linker "drops" updated llvm::Value * references
> in metadata.  Here goes an example.  We have a two-line source file
> a.c:
>
> static int x;
> void foo() { x = 1; }
>
> and a similar b.c:
>
> static int x;
> void bar() { x = 1; }
>
> They both have an internal variable x; one of them will be renamed (to
> x1) during linking.
>
> clang -emit-llvm -c -g a.c
> clang -emit-llvm -c -g b.c
> llvm-link -o t.bc a.o b.o
>
> Before linking we can see the following lines in both bitcode files
> from a.c and b.c, where the last element of !5 refers to the internal
> variable x.
>
> !llvm.dbg.sp = !{!1}
> !5 = metadata !{i32 655412, i32 0, metadata !0, metadata !"x",
> metadata !"x", metadata !"", metadata !2, i32 1, metadata !6, i32 1,
> i32 1, i32* @x} ; [ DW_TAG_variable ]
>
> However after linking the last element of !11 becomes null.  I was
> expecting that it would refer to the renamed x1.
>
> !llvm.dbg.gv = !{!9, !11}
> !9 = metadata !{i32 655412, i32 0, metadata !0, metadata !"x",
> metadata !"x", metadata !"", metadata !3, i32 1, metadata !10, i32 1,
> i32 1, i32* @x} ; [ DW_TAG_variable ]
> !11 = metadata !{i32 655412, i32 0, metadata !1, metadata !"x",
> metadata !"x", metadata !"", metadata !7, i32 1, metadata !12, i32 1,
> i32 1, null} ; [ DW_TAG_variable ]
>
> Is it intentional or a bug?  Thanks.

It's a bug, probably a regression. Please file a bugzilla report.
Thanks,
-
Devang
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: metadata linking bug or by design

Xi Wang
I looked at an earlier version.  NamedMDNodes were linked after global
values.  Current trunk version links NamedMDNodes before that, though
the comment says otherwise: "We do this after linking GlobalValues so
that MDNodes that reference GlobalValues are properly remapped".  see
ModuleLinker::run in lib/Linker/LinkModules.cpp.

If I move the call to linkNamedMDNodes in ModuleLinker::run to the
last step (just before return false), everything looks good.  Not sure
if linkNamedMDNodes must be called earlier.

- xi

On Thu, Aug 4, 2011 at 1:22 PM, Devang Patel <[hidden email]> wrote:

>
> On Aug 4, 2011, at 8:21 AM, Xi Wang wrote:
>
>> Hi,
>>
>> It seems that current linker "drops" updated llvm::Value * references
>> in metadata.  Here goes an example.  We have a two-line source file
>> a.c:
>>
>> static int x;
>> void foo() { x = 1; }
>>
>> and a similar b.c:
>>
>> static int x;
>> void bar() { x = 1; }
>>
>> They both have an internal variable x; one of them will be renamed (to
>> x1) during linking.
>>
>> clang -emit-llvm -c -g a.c
>> clang -emit-llvm -c -g b.c
>> llvm-link -o t.bc a.o b.o
>>
>> Before linking we can see the following lines in both bitcode files
>> from a.c and b.c, where the last element of !5 refers to the internal
>> variable x.
>>
>> !llvm.dbg.sp = !{!1}
>> !5 = metadata !{i32 655412, i32 0, metadata !0, metadata !"x",
>> metadata !"x", metadata !"", metadata !2, i32 1, metadata !6, i32 1,
>> i32 1, i32* @x} ; [ DW_TAG_variable ]
>>
>> However after linking the last element of !11 becomes null.  I was
>> expecting that it would refer to the renamed x1.
>>
>> !llvm.dbg.gv = !{!9, !11}
>> !9 = metadata !{i32 655412, i32 0, metadata !0, metadata !"x",
>> metadata !"x", metadata !"", metadata !3, i32 1, metadata !10, i32 1,
>> i32 1, i32* @x} ; [ DW_TAG_variable ]
>> !11 = metadata !{i32 655412, i32 0, metadata !1, metadata !"x",
>> metadata !"x", metadata !"", metadata !7, i32 1, metadata !12, i32 1,
>> i32 1, null} ; [ DW_TAG_variable ]
>>
>> Is it intentional or a bug?  Thanks.
>
> It's a bug, probably a regression. Please file a bugzilla report.
> Thanks,
> -
> Devang
>

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: metadata linking bug or by design

Devang Patel

On Aug 4, 2011, at 11:30 AM, Xi Wang wrote:

> I looked at an earlier version.  NamedMDNodes were linked after global
> values.  Current trunk version links NamedMDNodes before that, though
> the comment says otherwise: "We do this after linking GlobalValues so
> that MDNodes that reference GlobalValues are properly remapped".  see
> ModuleLinker::run in lib/Linker/LinkModules.cpp.
>
> If I move the call to linkNamedMDNodes in ModuleLinker::run to the
> last step (just before return false), everything looks good.  Not sure
> if linkNamedMDNodes must be called earlier.

I made  that change in response to Chris's change ValueMapper. Metadata mapping is being investigated as part of PR 10553 anyway. So Ill fix this particular regression you have found.
Thanks!
-
Devang

>
> - xi
>
> On Thu, Aug 4, 2011 at 1:22 PM, Devang Patel <[hidden email]> wrote:
>>
>> On Aug 4, 2011, at 8:21 AM, Xi Wang wrote:
>>
>>> Hi,
>>>
>>> It seems that current linker "drops" updated llvm::Value * references
>>> in metadata.  Here goes an example.  We have a two-line source file
>>> a.c:
>>>
>>> static int x;
>>> void foo() { x = 1; }
>>>
>>> and a similar b.c:
>>>
>>> static int x;
>>> void bar() { x = 1; }
>>>
>>> They both have an internal variable x; one of them will be renamed (to
>>> x1) during linking.
>>>
>>> clang -emit-llvm -c -g a.c
>>> clang -emit-llvm -c -g b.c
>>> llvm-link -o t.bc a.o b.o
>>>
>>> Before linking we can see the following lines in both bitcode files
>>> from a.c and b.c, where the last element of !5 refers to the internal
>>> variable x.
>>>
>>> !llvm.dbg.sp = !{!1}
>>> !5 = metadata !{i32 655412, i32 0, metadata !0, metadata !"x",
>>> metadata !"x", metadata !"", metadata !2, i32 1, metadata !6, i32 1,
>>> i32 1, i32* @x} ; [ DW_TAG_variable ]
>>>
>>> However after linking the last element of !11 becomes null.  I was
>>> expecting that it would refer to the renamed x1.
>>>
>>> !llvm.dbg.gv = !{!9, !11}
>>> !9 = metadata !{i32 655412, i32 0, metadata !0, metadata !"x",
>>> metadata !"x", metadata !"", metadata !3, i32 1, metadata !10, i32 1,
>>> i32 1, i32* @x} ; [ DW_TAG_variable ]
>>> !11 = metadata !{i32 655412, i32 0, metadata !1, metadata !"x",
>>> metadata !"x", metadata !"", metadata !7, i32 1, metadata !12, i32 1,
>>> i32 1, null} ; [ DW_TAG_variable ]
>>>
>>> Is it intentional or a bug?  Thanks.
>>
>> It's a bug, probably a regression. Please file a bugzilla report.
>> Thanks,
>> -
>> Devang
>>

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: metadata linking bug or by design

Xi Wang
Great!  Thanks!

I noticed this when I was creating my own metadata nodes, which
contained references to functions --- after linking some elements that
referred to functions magically became null.

- xi

On Thu, Aug 4, 2011 at 2:42 PM, Devang Patel <[hidden email]> wrote:

>
> On Aug 4, 2011, at 11:30 AM, Xi Wang wrote:
>
>> I looked at an earlier version.  NamedMDNodes were linked after global
>> values.  Current trunk version links NamedMDNodes before that, though
>> the comment says otherwise: "We do this after linking GlobalValues so
>> that MDNodes that reference GlobalValues are properly remapped".  see
>> ModuleLinker::run in lib/Linker/LinkModules.cpp.
>>
>> If I move the call to linkNamedMDNodes in ModuleLinker::run to the
>> last step (just before return false), everything looks good.  Not sure
>> if linkNamedMDNodes must be called earlier.
>
> I made  that change in response to Chris's change ValueMapper. Metadata mapping is being investigated as part of PR 10553 anyway. So Ill fix this particular regression you have found.
> Thanks!
> -
> Devang
>
>>
>> - xi
>>
>> On Thu, Aug 4, 2011 at 1:22 PM, Devang Patel <[hidden email]> wrote:
>>>
>>> On Aug 4, 2011, at 8:21 AM, Xi Wang wrote:
>>>
>>>> Hi,
>>>>
>>>> It seems that current linker "drops" updated llvm::Value * references
>>>> in metadata.  Here goes an example.  We have a two-line source file
>>>> a.c:
>>>>
>>>> static int x;
>>>> void foo() { x = 1; }
>>>>
>>>> and a similar b.c:
>>>>
>>>> static int x;
>>>> void bar() { x = 1; }
>>>>
>>>> They both have an internal variable x; one of them will be renamed (to
>>>> x1) during linking.
>>>>
>>>> clang -emit-llvm -c -g a.c
>>>> clang -emit-llvm -c -g b.c
>>>> llvm-link -o t.bc a.o b.o
>>>>
>>>> Before linking we can see the following lines in both bitcode files
>>>> from a.c and b.c, where the last element of !5 refers to the internal
>>>> variable x.
>>>>
>>>> !llvm.dbg.sp = !{!1}
>>>> !5 = metadata !{i32 655412, i32 0, metadata !0, metadata !"x",
>>>> metadata !"x", metadata !"", metadata !2, i32 1, metadata !6, i32 1,
>>>> i32 1, i32* @x} ; [ DW_TAG_variable ]
>>>>
>>>> However after linking the last element of !11 becomes null.  I was
>>>> expecting that it would refer to the renamed x1.
>>>>
>>>> !llvm.dbg.gv = !{!9, !11}
>>>> !9 = metadata !{i32 655412, i32 0, metadata !0, metadata !"x",
>>>> metadata !"x", metadata !"", metadata !3, i32 1, metadata !10, i32 1,
>>>> i32 1, i32* @x} ; [ DW_TAG_variable ]
>>>> !11 = metadata !{i32 655412, i32 0, metadata !1, metadata !"x",
>>>> metadata !"x", metadata !"", metadata !7, i32 1, metadata !12, i32 1,
>>>> i32 1, null} ; [ DW_TAG_variable ]
>>>>
>>>> Is it intentional or a bug?  Thanks.
>>>
>>> It's a bug, probably a regression. Please file a bugzilla report.
>>> Thanks,
>>> -
>>> Devang
>>>
>
>

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev