> We don't have any such plans, but patches are welcome. What would be the prerequisites for accepting this patch for upstream?
> You will need a change in the run-time library and in both compilers. :( Yup. I wonder whether my employer will like the fact that I work on Clang though (we're not using it here). > You mean, kasan (Kernel-AddressSanitizer)? > kasan is just a prototype, it's easier to play with the prototype this way. > Eventually it will have inlined checks. Ah, so out-of-line checking was done just because it was easier to implement? Not because you wanted to minimize kernel size? >> Memory savings would be quite significant which is important for >> mobile applications. > > You mean code size? (of course, it translates into memory usage) Yes. > I think that outlining the checks will cause dramatic slowdown > (instead of one load, you access memory 3 times: call > ... > ret True but branch predictor should be able to cope with these. It would be crucial to compile static implementation into every executable/DSO to avoid PLT call costs though. There is also usual cost associated with saving the context (caller-saved regs, flags, etc.) but this could be minimized if we use custom ABI for checking builtins (like for arithmetic libgcc builtins). -Y -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
