On Thu, 23 Dec 2021 at 13:10, Martin Liška wrote:
> >> On 11/22/21 20:01, Dmitry Vyukov wrote:
> >>> I've already reverted the change. So I will include a fix into the next
> >>> version.
> >>> Thanks for notifying.
> >>
> >>
On Mon, 29 Nov 2021 at 19:16, Martin Liška wrote:
>
> On 11/22/21 20:01, Dmitry Vyukov wrote:
> > I've already reverted the change. So I will include a fix into the next
> > version.
> > Thanks for notifying.
>
> Hello.
>
> Am I correct that the patc
On Tue, 23 Nov 2021 at 17:16, Florian Weimer wrote:
>
> * Dmitry Vyukov:
>
> > On Tue, 23 Nov 2021 at 14:59, Florian Weimer wrote:
> >>
> >> * Dmitry Vyukov:
> >>
> >> > Or what kind of integration do you mean? Tsan did not have any dire
On Tue, 23 Nov 2021 at 14:59, Florian Weimer wrote:
>
> * Dmitry Vyukov:
>
> > Or what kind of integration do you mean? Tsan did not have any direct
> > integration and worked with unmodified glibc.
>
> I thought there is a false-positive data race report if an initi
On Tue, 23 Nov 2021 at 14:49, Florian Weimer wrote:
>
> * Dmitry Vyukov via Gcc:
>
> > I wanted to give heads up regarding a significant re-design of the
> > ThreadSanitizer runtime:
> > https://reviews.llvm.org/D112603
> > Currently it's submitted:
> >
On Mon, 22 Nov 2021 at 19:38, Martin Liška wrote:
>
> On 11/22/21 16:22, Dmitry Vyukov wrote:
> > I wanted to give heads up regarding a significant re-design of the
> > ThreadSanitizer runtime:
> > https://reviews.llvm.org/D112603
> > Currently it's submitte
On Mon, 22 Nov 2021 at 19:31, Martin Liška wrote:
>
> On 11/22/21 16:22, Dmitry Vyukov wrote:
> > Hi gcc developers,
>
> Hello.
>
> >
> > I wanted to give heads up regarding a significant re-design of the
>
> Thanks for it.
>
> > ThreadSanitiz
Hi gcc developers,
I wanted to give heads up regarding a significant re-design of the
ThreadSanitizer runtime:
https://reviews.llvm.org/D112603
Currently it's submitted:
https://github.com/llvm/llvm-project/commit/1784fe0532a69ead17793bced060a9bf9d232027
but can well be rolled back if too many bui
On Sun, Feb 7, 2021 at 3:09 PM Kirill A. Shutemov wrote:
>
> On Sun, Feb 07, 2021 at 09:07:02AM +0100, Dmitry Vyukov wrote:
> > On Fri, Feb 5, 2021 at 4:43 PM H.J. Lu wrote:
> > >
> > > On Fri, Feb 5, 2021 at 7:16 AM Kirill A. Shutemov
> > > wrote:
>
On Fri, Feb 5, 2021 at 4:43 PM H.J. Lu wrote:
>
> On Fri, Feb 5, 2021 at 7:16 AM Kirill A. Shutemov
> wrote:
> >
> > Provide prctl() interface to enabled LAM for user addresses. Depending
> > how many tag bits requested it may result in enabling LAM_U57 or
> > LAM_U48.
>
> I prefer the alternate
;
>
> On Sun, Sep 3, 2017 at 12:19 PM, Dmitry Vyukov wrote:
>> On Sun, Sep 3, 2017 at 12:01 PM, Jakub Jelinek wrote:
>>> On Sun, Sep 03, 2017 at 10:50:16AM +0200, Dmitry Vyukov wrote:
>>>> What we instrument in LLVM is _comparisons_ rather than control
>>>
On Sun, Sep 3, 2017 at 12:19 PM, Dmitry Vyukov wrote:
> On Sun, Sep 3, 2017 at 12:01 PM, Jakub Jelinek wrote:
>> On Sun, Sep 03, 2017 at 10:50:16AM +0200, Dmitry Vyukov wrote:
>>> What we instrument in LLVM is _comparisons_ rather than control
>>> structures. So that w
On Sun, Sep 3, 2017 at 12:01 PM, Jakub Jelinek wrote:
> On Sun, Sep 03, 2017 at 10:50:16AM +0200, Dmitry Vyukov wrote:
>> What we instrument in LLVM is _comparisons_ rather than control
>> structures. So that would be:
>> _4 = x_8(D) == 98;
>> For example, resu
thing else that needs to be
> conditionalized.
>
> @@ -1943,6 +2032,12 @@ common_handle_option (struct gcc_options *opts,
> &= ~(SANITIZE_UNDEFINED | SANITIZE_UNDEFINED_NONDEFAULT);
>break;
>
> +case OPT_fsanitize_coverage_:
> + opts->x_flag_sanitize_coverage
> + = parse_coverage_sanitizer_o
On Sat, Jul 15, 2017 at 9:21 AM, 吴潍浠(此彼) wrote:
> Hi
>
> Implementing __sanitizer_cov_trace_cmp[1248]_const is OK .
> And I will try to find some determinate way to judge this comparison is for
> loop or not.
> Because all the loops(for() or while()) seem to be transformed to "if" and
> "goto" b
On Fri, Jul 14, 2017 at 11:17 PM, Kostya Serebryany wrote:
> Hi
>
> I wrote a test for "-fsanitize-coverage=trace-cmp" .
>
> Is there anybody tells me if these codes could be merged into gcc ?
Nice!
We are currently working on Linux kernel fuzzing
On Thu, Jul 13, 2017 at 11:18 PM, Kostya Serebryany wrote:
>> > Hi
>> >
>> > I wrote a test for "-fsanitize-coverage=trace-cmp" .
>> >
>> > Is there anybody tells me if these codes could be merged into gcc ?
>>
>>
>> Nice!
>>
>> We are currently working on Linux kernel fuzzing that use the
>> comp
>> meaningful, because programmers must have some reasons to do that. As
>> practice , "==" is more meaningful.
>>
>> 4.Should we record comparisons for counting loop checks ?
>> Not sure.
>>
>> With Regards
>> Wish Wu of Ant-financial Li
On Tue, Jul 11, 2017 at 1:59 PM, Wish Wu wrote:
> Hi
>
> I wrote a test for "-fsanitize-coverage=trace-cmp" .
>
> Is there anybody tells me if these codes could be merged into gcc ?
Nice!
We are currently working on Linux kernel fuzzing that use the
comparison tracing. We use clang at the momen
On Tue, Oct 14, 2014 at 3:07 PM, Yury Gribov wrote:
> On 09/18/2014 01:57 PM, Jakub Jelinek wrote:
>> On Thu, Sep 18, 2014 at 01:46:21PM +0400, Yury Gribov wrote:
>>> Kernel Asan patches are currently being discussed in LKML. One of the
>>> points>> raised during review was that KAsan requires GCC
On Wed, Oct 1, 2014 at 11:30 AM, VandeVondele Joost
wrote:
> Hi,
>
> I've noticed that gcc includes a msan_interface.h file, and I'm wondering if
> this implies that memory sanitizer is already part of gcc. If not, are there
> plans to port this useful looking tool to gcc during the current sta
On Thu, Sep 18, 2014 at 10:42 PM, Yury Gribov wrote:
> On 09/18/2014 09:33 PM, Dmitry Vyukov wrote:
>>
>> What is the number of cases it will fix for kasan?
>
>
> Re-added kernel people again.
>
> AFAIR silly instrumentation that assumed all memory accesses in
On Thu, Sep 18, 2014 at 4:09 AM, Yury Gribov wrote:
> Hi all,
>
> Current semantics of memory constraints in GCC inline asm (i.e. "m", "v",
> etc.) is somewhat loosy in that it tells GCC that asm code _may_ access
> given amount of bytes but is not guaranteed to do so. This is (ab)used by
> e.g. g
On Mon, Dec 17, 2012 at 11:58 AM, Jakub Jelinek wrote:
> Hi!
>
> I've noticed libtsan can't be installed via rpm, due to invalid use of
> dynamic linker's internals:
>
> #ifdef __i386__
> # define INTERNAL_FUNCTION __attribute__((regparm(3), stdcall))
> #else
> # define INTERNAL_FUNCTION
> #endif
24 matches
Mail list logo
