llvm dev - Sep 2010 - [LLVMdev] need pointers navigating through metadata in llvm :-)

Hi everyone, apologies for the mass spam, but I ran into an issue
involving debug metadata in the bitcode linking stage (using gold)

I am interested in helping out, so would like some pointers if possible.

The proximate cause of the issue in our local version of llvm is that
a Value is being written out, and the dump() of that value is actually
not a value at all, but what looks like a reference to a function. So
what happens is that  BitcodeWriter.cpp:WriteModuleConstants() is
barfing, because this particular Value is not any of the variants that
its made to handle.

It looks like the specific value in question is part of the debug
metadata generated by our local version (which is somewhere between
v2.7 and the llvm-tip, plus our local changes)

Interestingly enough, the .bc file (with debug info) generated by
vanilla llvm-gcc 2.7 passes through the gold bitcode linking stage
without issues - and after some futzing about, I narrowed the change
down to a single entry diff

The first one passes through link while the latter does not.

!0 = metadata !{i32 524334, i32 0, metadata !1, metadata !"main",
metadata !"main", metadata !"main", metadata !1, i32 5,
metadata !3,
i1 false, i1 true, i32 0, i32 0, null, i1 false, i1 false, i32 0} ; [
DW_TAG_subprogram ]

!0 = metadata !{i32 524334, i32 0, metadata !1, metadata !"main",
metadata !"main", metadata !"main", metadata !1, i32 5,
metadata !3,
i1 false, i1 true, i32 0, i32 0, null, i1 false, i1 false, i32 (i32,
i8**)* @main} ; [ DW_TAG_subprogram ]

The difference is the LAST entry (0 versus (i32, i8**)* @main), which
looks like the reference to the function itself, (in this case, it
happens to be "main" :-)

So the question is, what is the intent of the metadata type tag 46?
was it intended to have a reference to the actual function?  It looks
like the corresponding node as generated by llvm-2.7 is missing this
item. (I guess I should look up what the dwarf tag  subprogram is
supposed to have - that's on my todo queue :-)

So is this a metadata generation bug? or is this a metadata
consumption bug? or both?  I can maybe field a wild guess that this
particular Value should not be written out as a Constant at all, but
rather as a linkable reference?


Thank you.
-Jason Kim

Hi Jason,
> The proximate cause of the issue in our local version of llvm is that
> a Value is being written out, and the dump() of that value is actually
> not a value at all, but what looks like a reference to a function. So
> what happens is that  BitcodeWriter.cpp:WriteModuleConstants() is
> barfing, because this particular Value is not any of the variants that
> its made to handle.
does vanilla 2.8 or latest svn barf?  If so, that should anyways be fixed
since bitcode that passes the verifier shouldn't break the bitcode writer.
(Presumably it passes the verifier?)

Ciao,

Duncan.

Jason,

This looks like PR 7689.
-
Devang
On Sep 8, 2010, at 6:16 PM, Jason Kim wrote:
> Hi everyone, apologies for the mass spam, but I ran into an issue
> involving debug metadata in the bitcode linking stage (using gold)
> 
> I am interested in helping out, so would like some pointers if possible.
> 
> The proximate cause of the issue in our local version of llvm is that
> a Value is being written out, and the dump() of that value is actually
> not a value at all, but what looks like a reference to a function. So
> what happens is that  BitcodeWriter.cpp:WriteModuleConstants() is
> barfing, because this particular Value is not any of the variants that
> its made to handle.
> 
> It looks like the specific value in question is part of the debug
> metadata generated by our local version (which is somewhere between
> v2.7 and the llvm-tip, plus our local changes)
> 
> Interestingly enough, the .bc file (with debug info) generated by
> vanilla llvm-gcc 2.7 passes through the gold bitcode linking stage
> without issues - and after some futzing about, I narrowed the change
> down to a single entry diff
> 
> The first one passes through link while the latter does not.
> 
> !0 = metadata !{i32 524334, i32 0, metadata !1, metadata !"main",
> metadata !"main", metadata !"main", metadata !1, i32 5,
metadata !3,
> i1 false, i1 true, i32 0, i32 0, null, i1 false, i1 false, i32 0} ; [
> DW_TAG_subprogram ]
> 
> !0 = metadata !{i32 524334, i32 0, metadata !1, metadata !"main",
> metadata !"main", metadata !"main", metadata !1, i32 5,
metadata !3,
> i1 false, i1 true, i32 0, i32 0, null, i1 false, i1 false, i32 (i32,
> i8**)* @main} ; [ DW_TAG_subprogram ]
> 
> The difference is the LAST entry (0 versus (i32, i8**)* @main), which
> looks like the reference to the function itself, (in this case, it
> happens to be "main" :-)
> 
> So the question is, what is the intent of the metadata type tag 46?
> was it intended to have a reference to the actual function?  It looks
> like the corresponding node as generated by llvm-2.7 is missing this
> item. (I guess I should look up what the dwarf tag  subprogram is
> supposed to have - that's on my todo queue :-)
> 
> So is this a metadata generation bug? or is this a metadata
> consumption bug? or both?  I can maybe field a wild guess that this
> particular Value should not be written out as a Constant at all, but
> rather as a linkable reference?
> 
> 
> Thank you.
> -Jason Kim
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev