[M3devel] Target.First_readable_addr

[Jay]

Passing a ^ to a VAR imho should probably not count as a deref -- I agree with the implementation. Just like in C++ dereferencing a pointer to get a reference instead of a value. One wants a stack trace, and a runtime check maybe applied after the fact.
Ie. once we fault, show all nil parameters on the stack to all functions to help me fish for it. Not easy.


 - Jay

On Aug 26, 2015, at 8:37 AM, "Rodney M. Bates" <rodney_bates at lcwb.coop> wrote:

> I have always thought "segfault, could it be a NIL pointer deref?", or whatever
> words to that effect, was a rather lame excuse of an error message, and not
> much help.
> 
> Since this scheme doesn't fault at the point of the real deref, but afterwards, when a
> memory reference is actually made, possibly computed from that address, could the location
> given for the fault (whether line no or just code displacement) be wrong?  Very wrong?
> 
> TYPE A = ARRAY [ 0 .. 121 ] OF INTEGER;
> 
> PROCEDURE Q ( )
> = VAR Ptr : REF A := NIL;
>  BEGIN
>     P(Ptr^);           <---deref occurs here
>  END Q;
> 
> .... lots of other code, different module, etc. ...
> 
> PROCEDURE P ( VAR x : A )
> = BEGIN
>    x[119] := 17       <---memory ref & segfault don't happen until here.
>  END P;
> 
> Or is this scheme only used in selective places, such as implicit deref
> when putting a subscript onto a pointer? e.g.:
> 
> Ptr[117] := 43;
> 
> On 08/25/2015 07:28 PM, Jay K wrote:
>> Of course, my agenda is to remove target-specificity.
>> 
>> 
>> 
>> Target.First_readable_addr is a target-specific optimization
>> to omit null checks. Or maybe range checks..
>> 
>> 
>> The assumption is that dereferencing "actual" null is checked
>> by the hardware, so code doesn't have to be generated to check for null.
>> 
>> 
>> I'm not even sure I like this -- as the behavior of dereferencing null is not portable.
>> 
>> 
>> The assumption is further that accesses to the first page, at least,
>> are subject to the same hardware checks, and can also be optimized away.
>> 
>> 
>> At first, glance, I thought this was based on offset + size of a static access.
>> 
>> 
>> For example:
>> 
>> a: ARRAY [0...large] OF CHAR
>> 
>> 
>> a[0..4095]   no check
>> a[4096 and up] would check
>> 
>> 
>> Target.First_deadable_addr is 4k on many targets; 8k on others.
>> Setting it too low would yield extra checks.
>> Setting it too high would yield missing checks and a loss of safety.
>> 
>> 
>> Here is what I actually found though.
>> 
>> 
>>  - The check is based on the size of the type being accessed.
>> 
>>  - It is off by a factor of 8 -- there is confusing between m3middle and m3front
>>   as to if it is bit number of a byte number.
>> 
>> 
>> small: ARRAY[0..100] OF CHAR
>> large:ARRAY[0..100000] OF CHAR
>> 
>> no access to small gets checked and every access to larger gets checked.
>> 
>> Should we do anything about this?
>> 
>> In m3-sys/m3tests/src/p2/p263:
>> cm3 -realclean
>> cm3 -keep
>> grep fault <target>/*ms
>> 
>> 
>> All the accesses are to offset 0.
>> So, by some expectation, no null checks are needed.
>> Null checks are output when the size of the
>> containing type is, for x86, larger than 4096*8.
>> 
>> 
>> The checks have been largely but not completely wrong/missing.
>> Safety behooves us to check though.
>> 
>>  - fix the factor of 8?
>>  - make it 0?? too slow?
>>  - make it 4k on all target? until such time as a target manifests with a smaller page size?
>>  - base the checks on access offset + size, not containing size?
>>    Containing size is conservative. It checks more than i think is meant.
>> 
>> 
>> I couldn't actually figure out the code here, I added various:
>> 
>>     IF RTParams.IsPresent("qual") THEN
>>       RTIO.PutText("NilChkExpr.Compile p.offset:" & Fmt.Int(p.offset) & "\n");
>>       RTIO.Flush();
>>     END;
>> 
>> and such to m3front to figure it out.
>> 
>> 
>> Thanks,
>> - Jay
>> 
>> 
>> 
>> _______________________________________________
>> M3devel mailing list
>> M3devel at elegosoft.com
>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
> 
> -- 
> Rodney Bates
> rodney.m.bates at acm.org