llvm dev - Jul 2017 - Where does the LLVM implement the Ubsan's instrumentations?

> I think your best bet for controlling code bloat is to compile with 
> -fsanitize=undefined -fsanitize-trap=undefined.
Also you may not need all of UBSan's checks at the same time -- so pick 
and choose among its checks using the finer-grained flags.

If you're really stuck against a hard limit on code size, try applying 
UBSan to a subset of files in your project at a time.

John

> > I think your best bet for controlling code bloat is to compile with
> > -fsanitize=undefined -fsanitize-trap=undefined.
> 
> Also you may not need all of UBSan's checks at the same time -- so pick
> and choose among its checks using the finer-grained flags.
> 
> If you're really stuck against a hard limit on code size, try applying
> UBSan to a subset of files in your project at a time.
Hi John,
Thank your suggestion. I like the trap-funcion way. With the compile options
"-fsanitize=undefined -fsanitize-trap=undefined
-ftrap-function=__my_trap_function", my firmware can save +40% code size.
It is great!

But I have another question about the trap-function. I hope to print the wrong
code running IP address in my trap function (then, I can use llvm-symbolizer to
know its code location), and I also hope to print undefined behavior specific
type info, e.g. add_overflow, type_mismatch_v1, etc., which are defined in
compiler-rt\lib\ubsan\ubsan_interface.inc. How should I correctly define the
__my_sanitizer_trap() and let clang/llvm input relative info into my trap
function?

Thanks
Steven

> But I have another question about the trap-function. I hope to print the
wrong code running IP address in my trap function (then, I can use
llvm-symbolizer to know its code location), and I also hope to print undefined
behavior specific type info, e.g. add_overflow, type_mismatch_v1, etc., which
are defined in compiler-rt\lib\ubsan\ubsan_interface.inc. How should I correctly
define the __my_sanitizer_trap() and let clang/llvm input relative info into my
trap function?
IIRC nothing gets pushed onto the stack before your custom trap function 
is called. A bit of Clang hacking will be required if you want to alter 
this behavior.

John

> On Jul 21, 2017, at 6:04 AM, Shi, Steven via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
>>> I think your best bet for controlling code bloat is to compile with
>>> -fsanitize=undefined -fsanitize-trap=undefined.
>> 
>> Also you may not need all of UBSan's checks at the same time -- so
pick
>> and choose among its checks using the finer-grained flags.
>> 
>> If you're really stuck against a hard limit on code size, try
applying
>> UBSan to a subset of files in your project at a time.
> 
> Hi John,
> Thank your suggestion. I like the trap-funcion way. With the compile
options "-fsanitize=undefined -fsanitize-trap=undefined
-ftrap-function=__my_trap_function", my firmware can save +40% code size.
It is great!
You might try compiling with '-fsanitize=undefined
-fno-sanitize-recover=undefined'. You should still see some code size
savings with this option. You'll need to link in the ubsan runtime when
compiling in no-recovery mode, but the diagnostics will be better.

Ubsan doesn't provide an option of using callbacks to implement its
instrumentation. If the no-recovery mode won't work for you, it's pretty
simply to write a custom ubsan runtime that fits in a single object file.
That's what I ended up doing to sanitize our kernel (xnu), so I can offer
help if you decide to go down that path.

best
vedant
> 
> 
> But I have another question about the trap-function. I hope to print the
wrong code running IP address in my trap function (then, I can use
llvm-symbolizer to know its code location), and I also hope to print undefined
behavior specific type info, e.g. add_overflow, type_mismatch_v1, etc., which
are defined in compiler-rt\lib\ubsan\ubsan_interface.inc. How should I correctly
define the __my_sanitizer_trap() and let clang/llvm input relative info into my
trap function?
> 
> Thanks
> Steven
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev