Hi Jakub,
On Tue, Nov 18, 2014 at 11:36 AM, Alexey Samsonov wrote:
>
> On Mon, Nov 17, 2014 at 11:53 PM, Jakub Jelinek wrote:
> > On Mon, Nov 17, 2014 at 11:39:47PM -0800, Alexey Samsonov wrote:
> >> > That is not what I think we've agreed on and what is implemen
On Mon, Nov 17, 2014 at 11:53 PM, Jakub Jelinek wrote:
> On Mon, Nov 17, 2014 at 11:39:47PM -0800, Alexey Samsonov wrote:
>> > That is not what I think we've agreed on and what is implemented in GCC.
>> > -fsanitize-recover only enables recovery of the undefine
On Mon, Nov 17, 2014 at 10:47 PM, Jakub Jelinek wrote:
>
> On Mon, Nov 17, 2014 at 06:40:00PM -0800, Alexey Samsonov wrote:
> > I've just prepared a patch implementing -fsanitize-recover= in
> > Clang (http://reviews.llvm.org/D6302), writing here to make sure we're
&g
LL_RETURN
> : BUILT_IN_UBSAN_HANDLE_NONNULL_RETURN_ABORT;
> tree fn = builtin_decl_explicit (bcode);
> --- gcc/c-family/c-ubsan.c.jj 2014-09-10 11:20:49.0 +0200
> +++ gcc/c-family/c-ubsan.c 2014-10-17 17:13:14.393241619 +0200
> @@ -104,7 +104,7 @@ ubsan_instrument_division (location_t lo
> NULL_TREE);
>data = build_fold_addr_expr_loc (loc, data);
>enum built_in_function bcode
> - = flag_sanitize_recover
> + = (flag_sanitize_recover & SANITIZE_DIVIDE)
> ? BUILT_IN_UBSAN_HANDLE_DIVREM_OVERFLOW
> : BUILT_IN_UBSAN_HANDLE_DIVREM_OVERFLOW_ABORT;
>tt = builtin_decl_explicit (bcode);
> @@ -199,7 +199,7 @@ ubsan_instrument_shift (location_t loc,
>data = build_fold_addr_expr_loc (loc, data);
>
>enum built_in_function bcode
> - = flag_sanitize_recover
> + = (flag_sanitize_recover & SANITIZE_SHIFT)
> ? BUILT_IN_UBSAN_HANDLE_SHIFT_OUT_OF_BOUNDS
> : BUILT_IN_UBSAN_HANDLE_SHIFT_OUT_OF_BOUNDS_ABORT;
>tt = builtin_decl_explicit (bcode);
> @@ -229,7 +229,7 @@ ubsan_instrument_vla (location_t loc, tr
> NULL_TREE);
>data = build_fold_addr_expr_loc (loc, data);
>enum built_in_function bcode
> - = flag_sanitize_recover
> + = (flag_sanitize_recover & SANITIZE_VLA)
> ? BUILT_IN_UBSAN_HANDLE_VLA_BOUND_NOT_POSITIVE
> : BUILT_IN_UBSAN_HANDLE_VLA_BOUND_NOT_POSITIVE_ABORT;
>tt = builtin_decl_explicit (bcode);
>
>
> Jakub
--
Alexey Samsonov, Mountain View, CA
On Wed, Oct 1, 2014 at 10:58 PM, Jakub Jelinek wrote:
> On Wed, Oct 01, 2014 at 04:21:29PM -0700, Alexey Samsonov wrote:
>> Speaking of plain -f(no-)sanitize-recover - it would probably be
>> better to change the semantics of this flag,
>> so that "-f(no-)?sanitize-reco
example,
"-fsanitize=undefined -fsanitize=address -fno-sanitize-recover"
would mean "run UBSan and ASan and don't recover from errors".
On Tue, Sep 30, 2014 at 10:39 AM, Jakub Jelinek wrote:
> On Tue, Sep 30, 2014 at 10:36:34AM -0700, Alexey Samsonov wrote:
>> >
On Tue, Sep 30, 2014 at 10:33 AM, Jakub Jelinek wrote:
> On Tue, Sep 30, 2014 at 10:26:39AM -0700, Alexey Samsonov wrote:
>> > I think we can summarize:
>> > * the current option -fsanitize-recover is misleading; it's really
>> > -fubsan-recover
>> > *
quot;-fsanitize-recover" will be a deprecated alias of
"-fsanitize-recover=undefined", and
"-fno-sanitize-recover" will be a deprecated alias of
"-fno-sanitize-recover=undefined".
If a user provides "-fsanitize-recover=address", we can instruct the
instrumentation pass to
use recoverable instrumentation.
>
> -Y
>
--
Alexey Samsonov, Mountain View, CA
On Mon, Sep 29, 2014 at 5:24 PM, Konstantin Serebryany
wrote:
>
> On Mon, Sep 29, 2014 at 4:26 PM, Alexey Samsonov wrote:
> > On Mon, Sep 29, 2014 at 4:17 PM, Jakub Jelinek wrote:
> >> On Mon, Sep 29, 2014 at 03:36:20PM -0700, Alexey Samsonov wrote:
> >>> -fasan
On Mon, Sep 29, 2014 at 4:17 PM, Jakub Jelinek wrote:
> On Mon, Sep 29, 2014 at 03:36:20PM -0700, Alexey Samsonov wrote:
>> -fasan-recover doesn't look like a good idea - for instance, in Clang, we
>> never use "?san"
>> in flag names, preferring -fsanitize-w
ere no way to keep a single -f(no-)sanitize-recover for that
purpose? Now it works
only for UBSan checks, but we may extend it to another sanitizers as well.
On Mon, Sep 29, 2014 at 2:20 PM, Konstantin Serebryany
wrote:
> +Alexey Samsonov
>
> On Mon, Sep 29, 2014 at 10:43 AM, Jakub Jelinek w
m.
>>> If it gets any change in the GCC variant, I will not be able to do
>>> merges from upstream until the same code is applied upstream.
>>
>> Sure, but we are nearing GCC 4.9 stage3 finish and really need to demangle
>> the libbacktrace provided output. Has the compiler-rt situation been
>> cleared up?
>
> I hope it just did (see the fresh Chandler's reply).
>
> --kcc
>
>> Haven't seen any follow-ups after Chandler's reversion.
>> So, this change is meant to be temporary, with hope that in upstream this
>> will be resolved, either with the same patch or something similar.
>>
>> Jakub
--
Alexey Samsonov, MSK
: name;
>> }
>> and uses it where it wants to demangle?
>
> I would say this is a defect. It's symbolizer responsibility.
>
>> From what I can see, even when
>> you are using llvm-symbolizer, sanitizer_common doesn't pass -demangle
>> option to it.
>
>
> It defaults to true:
> static cl::opt
> ClDemangle("demangle", cl::init(true), cl::desc("Demangle function names"));
--
Alexey Samsonov, MSK
On Wed, Nov 27, 2013 at 9:44 PM, Ian Lance Taylor wrote:
> On Wed, Nov 27, 2013 at 4:31 AM, Alexey Samsonov wrote:
>>
>> LLVM emits just a DW_AT_low_pc ("base address" of a compilation unit). The
>> standard tells that compilation unit entries "may have"
On Wed, Nov 27, 2013 at 4:51 PM, Jakub Jelinek wrote:
> On Wed, Nov 27, 2013 at 04:31:48PM +0400, Alexey Samsonov wrote:
>> LLVM emits just a DW_AT_low_pc ("base address" of a compilation unit). The
>> standard tells that compilation unit entries "may have" attr
On Wed, Nov 27, 2013 at 4:20 PM, Jakub Jelinek wrote:
> On Wed, Nov 27, 2013 at 04:12:33PM +0400, Alexey Samsonov wrote:
>> > Sure, worst case you keep it untested in your LLVM copy of libsanitizer
>> > and we'll just need to fix it up during merges if something break
On Mon, Nov 25, 2013 at 7:02 PM, Jakub Jelinek wrote:
> On Mon, Nov 25, 2013 at 06:53:59PM +0400, Alexey Samsonov wrote:
>> > In GCC, libbacktrace is built as a libtool convenience library only and
>> > then linked into whatever libraries want to use it. So indeed, the
On Fri, Nov 22, 2013 at 10:34 PM, Jakub Jelinek wrote:
> On Fri, Nov 22, 2013 at 10:19:02PM +0400, Alexey Samsonov wrote:
>> On Tue, Nov 19, 2013 at 8:42 PM, Jakub Jelinek wrote:
>> > Ok, here it is (untested though, because libsanitizer in gcc is older and I
>> > don&
0 ||
> + libbacktrace_symbolizer_ != 0 ||
> + external_symbolizer_ != 0;
>}
>
>bool IsExternalAvailable() {
> @@ -573,14 +597,19 @@ class POSIXSymbolizer : public Symbolize
>
>ExternalSymbolizer *external_symbolizer_;// Leaked.
>InternalSymbolizer *const internal_symbolizer_; // Leaked.
> + LibbacktraceSymbolizer *libbacktrace_symbolizer_; // Leaked.
> };
>
> Symbolizer *Symbolizer::PlatformInit(const char *path_to_external) {
>InternalSymbolizer* internal_symbolizer =
>InternalSymbolizer::get(&symbolizer_allocator_);
> + LibbacktraceSymbolizer* libbacktrace_symbolizer = 0;
>ExternalSymbolizer *external_symbolizer = 0;
>
> - if (!internal_symbolizer) {
> + if (!internal_symbolizer)
> +libbacktrace_symbolizer =
> + LibbacktraceSymbolizer::get(&symbolizer_allocator_);
> + if (!internal_symbolizer && !libbacktrace_symbolizer) {
> if (!path_to_external || path_to_external[0] == '\0')
>path_to_external = FindPathToBinary("llvm-symbolizer");
>
> @@ -593,7 +622,8 @@ Symbolizer *Symbolizer::PlatformInit(con
>}
>
>return new(symbolizer_allocator_)
> - POSIXSymbolizer(external_symbolizer, internal_symbolizer);
> + POSIXSymbolizer(external_symbolizer, libbacktrace_symbolizer,
> + internal_symbolizer);
> }
>
> } // namespace __sanitizer
>
>
> Jakub
--
Alexey Samsonov, MSK
Hi Jakub,
Can you please an updated patch in the attachment?
On Mon, Nov 18, 2013 at 8:23 PM, Jakub Jelinek wrote:
> On Mon, Nov 18, 2013 at 07:50:33PM +0400, Alexey Samsonov wrote:
>> On Mon, Nov 18, 2013 at 7:49 PM, Alexey Samsonov wrote:
>> Unfortunately, recently t
(resending in plain text)
On Mon, Nov 18, 2013 at 7:49 PM, Alexey Samsonov wrote:
Hi Jakub,
Unfortunately, recently there were a few enhancements to
sanitizer_symbolizer_posix_libcdep.cc (and friends),
in LLVM trunk, and now it looks different from gcc version (apparently, the
changes were
21 matches
Mail list logo
