Svadev mailing list

["Adve, Vikram Sadanand" <vadve AT illinois.edu>]

It's not just for greatest safety: I think Option 2 is the *right* way to do 
it and the other two are not -- they're just hacks to turn off the spurious 
error.

How useful will exactcheck be?  I'm not sure it will provide much benefit 
since these stdlib calls are likely to be called relatively infrequently in 
terms of time between calls.

--Vikram


On Jul 11, 2011, at 11:40 AM, John Criswell wrote:

> On 7/11/11 11:23 AM, Matthew Wala wrote:
>> On Mon, Jul 11, 2011 at 11:10 AM, John 
>> Criswell<criswell AT illinois.edu>
>>   wrote:
>>> On 7/11/11 11:06 AM, Matthew Wala wrote:
>>> 
>>> Hello everyone:
>>> When I compile the attached test case with SAFECode (tried on asha and
>>> bach) I get a large number of Out of Bounds / Load Store errors. The
>>> test calls gmtime() which returns static memory. These errors also
>>> occur if the function that is called is replaced with localtime().
>>> 
>>> Check to see if gmtime() and localtime() are recognized by DSA's StdLib
>>> pass.  If so, then what is probably happening is that they are being 
>>> marked
>>> complete, but since the memory objects aren't registered, you get an 
>>> error.
>> I did check, and there are entries for those functions in StdLibPass.
>> There's also entries for ctime() and asctime(). It looks like all four
>> of those functions have the same flags in the StdLibPass table, but
>> despite that the error still occurs. Perhaps the flags are wrong.
> 
> So, you have a couple of options for how to fix this:
> 
> 1) Modify the StdLibPass to mark the DSNode of the static memory with 
> the External flag.
> 2) Modify SAFECode to register the memory returned by these functions 
> into a pool.
> 3) Modify SAFECode's CompleteChecks pass to not make these memory 
> objects complete.
> 
> Option 2 is probably the best as it will provide the greatest safety.
> 
> It may also be worth enhancing the exactcheck optimization pass to treat 
> these functions like allocators.  I'd be willing to bet that many of 
> these memory objects are only accessed within the function in which they 
> are called and would benefit from the exactcheck optimization.
> 
> -- John T.
> 
>> 
>> I tested ctime() once more, and it looks that reading the output from
>> ctime() actually does cause a Load / Store error.
>> (The reason my previous testing didn't recognize this is that I did a
>> simple printf("%s\n", ctime(...)); call, and it looks like the C
>> frontend lowers such calls to puts(), which SAFECode doesn't currently
>> handle (I think I should probably add support for puts() in the
>> CStdLib pass for this reason). So the read of the value of ctime() was
>> being done in external code, which is why it didn't raise any errors.)
>> 
>> Matt
>> 
>>> If other functions aren't recognized by DSA's StdLib pass, then the 
>>> pointer
>>> is being marked External, which means that SAFECode won't raise an error 
>>> if
>>> the memory object isn't found in the pool.
>>> 
>>> -- John T.
>>> 
>>> However, other time-related functions that return static memory like
>>> ctime() (as well as the reentrant versions of gmtime() and
>>> localtime()) do not cause SAFECode to complain.
>>> Before filing a bug I'd like to know if there is a reason for this
>>> behavior or if this is already known.
>>> 
>>> Thanks,
>>> Matt
>>> 
>>> 
>>> _______________________________________________
>>> svadev mailing list
>>> svadev AT cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/svadev
>>> 
>>> 
> 
> _______________________________________________
> svadev mailing list
> svadev AT cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/svadev