correct email.
Am Montag, dem 15.07.2024 um 09:19 +0200 schrieb Martin Uecker:
> This is the third revision for my patch series to check bounds
> consistency at run-time when assigning VM types. Relative
> to the last version, mostly the tests were simplified and some
> coding style issues fixed.
>
>
> It adds a new code instrumentation option that inserts
> run-time checks to ensure bounds are matching. This helps
> with bounds safe programming and also finds problems in
> numerical code, e.g. when bound are swapped in
> multi-dimensional arrays
>
> void foo(int x, int y, double m[x][y]);
>
> double m[10][20];
> foo(20, 10, m);
>
> where currently do not get a warning or check.
>
> (After updating this patch series and testing it, it
> found a bug in new code added recently to my BART
> project - a numerical toolbox for image reconstruction and
> machine learning for magnetic resonance imaging.)
>
>
>
> The patches in the series do:
>
> 1. Checks simple assignments.
>
> 2. In addition checks function calls under the assumption
> that size expressions are declared as in the definition.
> This assumption goes beyond what ISO C guarantees (and is
> one reason this is not part of the UB sanitizer, the other
> is that there is no library support of this use case) but
> any inconsistency would usually indicate a bug anyway and
> we warn already by default with -Wvla-parameter
> (this now becomes really useful)
>
> 3. Checks function calls via pointers when possible.
>
> 4. Adds a warning if a function calls can not be
> instrumented e.g. because size expressions do not simply
> references to other parameters or variables. Also adds
> documentation for the warning and about instrumentation
> of function calls.
>
>
> The code is fairly simple and FE only as during recursive type
> checking in the comptypes family of function we can simply collect
> all pairs of size expressions that are supposed to match. This
> list is then further processed to emit simple checking code.
>
> For functions the main complication is that we need to evalute
> size expressions in the caller. We therefor only add
> checking if all size expressions direcly refer to other
> declarations, and simply give up for anything more complex.
> This already covers the most important use cases though.
>
>
> The code is also useful infrastructure for future compile-time
> warnings, e.g. the simply example above should clearly be
> diagnosed already compile time.
>
> I haven't implemented this yet, but this should be simple to add
> by detecting obvious cases during processing of the list of size
> expressions.
>
> Other current limitations are:
>
> The outermost bounds for functions parameters are not checked because
> they are lost when the type is adjusted to a pointer. The right semantics
> of checking those are also less obvious.
>
> As mentioned above, for functions we only check very simple size
> expressions that directly refer to a parameter or argument. It would
> be useful to extend this to more complex expressions without side
> effects, such 'n + 1' or maybe even 'n + m'. This would then cover
> most use cases in numerical code.
>
> A bounds violation just causes a run-time trap without error message.
> This is sufficient for safety and debugging with a debugger, but one
> consider adding a short error message. (This would have to go into
> libgcc I guess).
>
>
>
> The instrumentation is guarded by a new instrumentation flag -fvla-bounds,
> but runtime overhead should generally be very low as most checks are
> removed by the optimizer, e.g.
>
> void foo(int x, char (*buf)[x])
> {
> bar(x, buf);
> }
>
> does not have any overhead with -O1 (we also might want to filter out
> some obvious cases already in the FE). So I think this flag could be
> a good addition to -fhardened after some testing. Maybe it could even
> be activated by default.
>
>
> Finally, I am unsure about the use if signals in the tests. Maybe this
> is not supported everywhere? Any recommendation is much appreciated.
>
>
> Each patch was bootstrapped and regression tested on x86_64.
>
>
> Martin
>
>
>
>
>
>
>
>
>
>
--
Univ.-Prof. Dr. rer. nat. Martin Uecker
Graz University of Technology
Institute of Biomedical Imaging
