[llvm] r186634 - Debug Info: enable verifying by default and disable testing cases that fail.

[Eric Christopher]

Hi guys,

Swear I've mentioned this before, but no entity requires a DW_AT_name.
That said, are we sure we should be generating an entity for a
constant? What's the source look like here?

-eric

On Fri, Jul 19, 2013 at 10:54 AM, manman ren <manman.ren at gmail.com> wrote:
> Hi Duncan,
>
> That is exactly what happened, DIGlobalVariable::Verify enforces a display
> name, which seems unnecessary.
> Eric, any opinion on this?
>
> Thanks,
> Manman
>
>
> On Fri, Jul 19, 2013 at 1:21 AM, Duncan Sands <baldrick at free.fr> wrote:
>>
>> Hi Manman,
>>
>> On 19/07/13 07:07, Manman Ren wrote:
>>>
>>>
>>> Hi Duncan,
>>>
>>> How can I debug the failures?
>>
>>
>> this is coming from Fortran that likes to create anonymous global
>> constants
>> like this:
>>
>>   @0 = internal constant i32 77
>>
>> I think it's so that it can pass a pointer to "77" around.  Anyway, the
>> debug
>> code uses the name of the global as the "display name" but here there is
>> none.
>> The verifier then barfs because it thinks everything should have a name.
>>
>> I'm not sure why LLVM has this obsession that everything should have a
>> name.
>> Is there a real reason for that?  If dwarf requires a name, then in this
>> kind
>> of case someone will have to invent one.  The question then is whether it
>> is
>> better to require front-ends to always supply a name (meaning the
>> front-end has
>> to invent one), or to accept empty names and have the backend make
>> something up
>> when outputting dwarf.  Any opinions?
>>
>> Ciao, Duncan.
>>
>>
>>> Also getDICompositeType is not used on mainline but is used on dragonegg,
>>> how
>>> can I figure out the usage?
>>> Do  I have access to the source?
>>>
>>> Thanks,
>>> Manman
>>>
>>> On Jul 18, 2013, at 8:56 PM, Eric Christopher wrote:
>>>
>>>> Also this appears to have broken the dragonegg bots. :)
>>>>
>>>> -eric
>>>>
>>>> On Thu, Jul 18, 2013 at 6:08 PM, Eric Christopher <echristo at gmail.com
>>>> <mailto:echristo at gmail.com>> wrote:
>>>>>>
>>>>>> Debug Info: enable verifying by default and disable testing cases that
>>>>>> fail.
>>>>>>
>>>>>> 1> Use DebugInfoFinder to find debug info MDNodes.
>>>>>> 2> Add disable-debug-info-verifier to disable verifying debug info.
>>>>>> 3> Disable verifying for testing cases that fail (will update the
>>>>>> testing cases
>>>>>>   later on).
>>>>>> 4> MDNodes generated by clang can have empty filename for
>>>>>> TAG_inheritance and
>>>>>>   TAG_friend, so DIType::Verify is modified accordingly.
>>>>>>
>>>>>
>>>>> Cool, looks about like what I'd expected from when we discussed it.
>>>>> I'd have preferred you split out the change to verify :)
>>>>>
>>>>>> Note that DebugInfoFinder does not list all debug info MDNode.
>>>>>
>>>>>
>>>>> Seems like we should fix this? :)
>>>>>
>>>>>> For example, clang can generate:
>>>>>> metadata !{i32 786468}, which will fail to verify.
>>>>>
>>>>>
>>>>> This doesn't seem related to "not listing" all of the debug info, but
>>>>> a problem because of:
>>>>>
>>>>>> This MDNode is used by debug info but not included in DebugInfoFinder.
>>>>>> This MDNode is generated as a temporary node in
>>>>>> DIBuilder::createFunction
>>>>>>  Value *TElts[] = { GetTagConstant(VMContext, DW_TAG_base_type) };
>>>>>>  MDNode::getTemporary(VMContext, TElts)
>>>>>>
>>>>>
>>>>> This is the "we need a temporary placeholder" problem basically.
>>>>> You'll see it in GVs, subprograms etc when we construct the CU as
>>>>> well. Theoretically the verifier should catch these as "not
>>>>> important". What's actually going on here that's causing it to fail?
>>>>>
>>>>> -eric
>>>>> _______________________________________________
>>>>> llvm-commits mailing list
>>>>> llvm-commits at cs.uiuc.edu <mailto:llvm-commits at cs.uiuc.edu>
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>>
>>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>