[llvm] r196158 - Debug Info: drop debug info via upgrading path if version number does not match.

Eric Christopher echristo at gmail.com
Mon Dec 2 16:48:00 PST 2013


On Mon, Dec 2, 2013 at 4:34 PM, Manman Ren <manman.ren at gmail.com> wrote:
>
>
>
> On Mon, Dec 2, 2013 at 4:26 PM, Eric Christopher <echristo at gmail.com> wrote:
>>
>> On Mon, Dec 2, 2013 at 4:21 PM, Manman Ren <manman.ren at gmail.com> wrote:
>> >
>> >
>> >
>> > On Mon, Dec 2, 2013 at 2:07 PM, Eric Christopher <echristo at gmail.com>
>> > wrote:
>> >>
>> >> > Add a helper function getDebugInfoVersionFromModule to return the
>> >> > debug
>> >> > info
>> >> > version number for a module.
>> >> >
>> >>
>> >> I think this should be getDebugMetadataVersionFromModule since this
>> >> could be easily confused with the dwarf version that someone has asked
>> >> for.
>> >
>> >
>> > Done in r196172.
>> >>
>> >>
>> >> > "Verifier/module-flags-1.ll" checks for verification errors.
>> >> > It will seg fault when calling getDebugInfoVersionFromModule because
>> >> > of
>> >> > the
>> >> > incorrect format for module flags in the testing case. We make
>> >> > getModuleFlagsMetadata more robust by checking for error conditions.
>> >> >
>> >>
>> >> I'm not sure what's going on here, can you elaborate?
>> >
>> >
>> > We have the code path and the verification path. Code path should not
>> > seg
>> > fault when the format of a module flag is incorrect (as in the testing
>> > case
>> > Verifier/module-flags-1.ll).
>> > module-flags-1.ll tries to make sure that the verifier dumps the right
>> > error
>> > message when the format of a module flag is incorrect.
>> >
>> > Before this patch, the code path will seg fault because we don't perform
>> > error checking in the code path as shown below.
>> >
>>
>> You seem to be hard coding certain operations leading me to believe
>> there's some specific format here that you're looking for, but it's
>> not obvious what it is
>
>
> Can you be specific on where I am hard coding operations?

When you check for which operand is where. In other words:

+    if (Flag->getNumOperands() >= 3 && isa<ConstantInt>(Flag->getOperand(0)) &&
+        isa<MDString>(Flag->getOperand(1))) {
+      // Check the operands of the MDNode before accessing the operands.
+      // The verifier will actually catch these failures.
+      ConstantInt *Behavior = cast<ConstantInt>(Flag->getOperand(0));
+      MDString *Key = cast<MDString>(Flag->getOperand(1));
+      Value *Val = Flag->getOperand(2);
+      Flags.push_back(ModuleFlagEntry(ModFlagBehavior(Behavior->getZExtValue()),
+                                      Key, Val));

here.

>
>>
>> - are you saying that if you turn off the
>> verifier we'll crash on certain types of bitcode files that normally
>> we wouldn't be able to read anyhow since we'd fail verification?
>
>
> No, it does not matter whether the verifier is on or off. The code path
> should not seg fault when the input bit code has incorrect module flag.
>
> The reason my patch exposes the seg fault is that we parse the module flag
> before
> the verifier and the testing case will seg fault before getting the
> verification error.
>

This seems to me to be an indication that we're doing this in the
wrong location. I think it might be more clean if we were to run the
IR verifier and then as a separate pass to verify debug info metadata
that will also strip if the version number isn't what's expected.
Seems to have the right mental sequencing at least.

-eric



> Manman
>
>>
>>
>> -eric
>>
>> > Cheers,
>> > Manman
>> >
>> >>
>> >>
>> >> > Modified: llvm/trunk/lib/IR/Module.cpp
>> >> > URL:
>> >> >
>> >> > http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/IR/Module.cpp?rev=196158&r1=196157&r2=196158&view=diff
>> >> >
>> >> >
>> >> > ==============================================================================
>> >> > --- llvm/trunk/lib/IR/Module.cpp (original)
>> >> > +++ llvm/trunk/lib/IR/Module.cpp Mon Dec  2 15:29:56 2013
>> >> > @@ -318,11 +318,16 @@ getModuleFlagsMetadata(SmallVectorImpl<M
>> >> >
>> >> >    for (unsigned i = 0, e = ModFlags->getNumOperands(); i != e; ++i)
>> >> > {
>> >> >      MDNode *Flag = ModFlags->getOperand(i);
>> >> > -    ConstantInt *Behavior = cast<ConstantInt>(Flag->getOperand(0));
>> >> > -    MDString *Key = cast<MDString>(Flag->getOperand(1));
>> >> > -    Value *Val = Flag->getOperand(2);
>> >> > -
>> >> >
>> >> > Flags.push_back(ModuleFlagEntry(ModFlagBehavior(Behavior->getZExtValue()),
>> >> > -                                    Key, Val));
>> >> > +    if (Flag->getNumOperands() >= 3 &&
>> >> > isa<ConstantInt>(Flag->getOperand(0)) &&
>> >> > +        isa<MDString>(Flag->getOperand(1))) {
>> >> > +      // Check the operands of the MDNode before accessing the
>> >> > operands.
>> >> > +      // The verifier will actually catch these failures.
>> >> > +      ConstantInt *Behavior =
>> >> > cast<ConstantInt>(Flag->getOperand(0));
>> >> > +      MDString *Key = cast<MDString>(Flag->getOperand(1));
>> >> > +      Value *Val = Flag->getOperand(2);
>> >> > +
>> >> >
>> >> > Flags.push_back(ModuleFlagEntry(ModFlagBehavior(Behavior->getZExtValue()),
>> >> > +                                      Key, Val));
>> >> > +    }
>> >> >    }
>> >> >  }
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > llvm-commits mailing list
>> >> > llvm-commits at cs.uiuc.edu
>> >> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>> >
>> >
>
>



More information about the llvm-commits mailing list