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 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 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 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"
: 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
(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
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
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
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&
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 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
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
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
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
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
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
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 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
>> > *
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 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
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
21 matches
Mail list logo
