[LLVMdev] Verifier should not make any assumptions about calls to "malloc"

Victor Hernandez vhernandez at apple.com
Tue Sep 22 11:51:35 PDT 2009


On Sep 22, 2009, at 11:23 AM, Victor Hernandez wrote:

> On Sep 22, 2009, at 6:11 AM, Duncan Sands wrote:
>
>> Hi Victor, this code from the verifier broke the Ada front-end build:
>>
>> const Module* M = CI.getParent()->getParent()->getParent();
>> Constant *MallocFunc = M->getFunction("malloc");
>>
>> if (CI.getOperand(0) == MallocFunc) {
>>   const PointerType *PTy =
>> PointerType::getUnqual(Type::getInt8Ty(CI.getParent()->getContext 
>> ()));
>>   Assert1(CI.getType() == PTy, "Malloc call must return i8*", &CI);
>> }
>>
>> I think it is completely wrong for the verifier to be checking
>> anything
>> about calls to functions that happen to be called "malloc".  What  
>> if I
>> have my own runtime in which "malloc" is completely different to the
>> usual one?  From my reading of the gcc docs, malloc is not provided
>> in a freestanding environment and thus cannot be assumed to be the
>> normal malloc.
>
> What does the Ada front-end declare malloc as?
>
>>
>> I think this code should be removed from the verifier.  Instead,
>> isMalloc should also check the number of parameters and their types,
>> as well as the return value.
>
> The verifier code is needed because when a malloc return value is used
> directly, not via a bitcast, the type of the malloc is determined to
> be i8*.  But that could be updated to use the declared return type of
> malloc.  I need to understand more about how this is breaking Ada to
> determine how to resolve this.  Removing this check from the verifier
> could end up being the resolution.

Just looked at getMallocType() and it does not assume that the return  
type of a malloc call is i8*, so I have removed this check from the  
verifier.

Victor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090922/6baa52c9/attachment.html>


More information about the llvm-dev mailing list