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.
> >>
> >> Hello.
> >>
> >> Am I correct that the patch set is installed again? An
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 patch set is installed again? Any near future plans
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 direct
> >> > integration and worked with unmodified glibc.
> >>
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 initial-exec
> or local-exec TLS var
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 submitted:
> > https://github.com/llvm/llvm-proj
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.
>
> > ThreadSanitizer runtime:
> > https://reviews.llvm.org/D112603
> > Cu
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:
> > > >
> > > > Provide prctl() interface to en
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:38 PM, 吴潍浠(此彼) wrote:
> Hi
> I will update the patch according to your requirements, and with some my
> suggestions.
> It will take me one or two days.
Thanks! No hurry, just wanted to make sure you still want to pursue this.
> Wish Wu
>
> -
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 would be:
>>> _4 = x_8(D)
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, result of the comparison can be store
On Fri, Sep 1, 2017 at 6:23 PM, Jakub Jelinek wrote:
> On Fri, Jul 21, 2017 at 01:38:17PM +0800, 吴潍浠(此彼) wrote:
>> Hi Jeff
>>
>> I have signed the copyright assignment, and used the name 'Wish Wu' .
>> Should I send you a copy of my assignment ?
>>
>> The attachment is my new patch with small chan
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
On Thu, Jul 13, 2017 at 12:41 PM, Wish Wu wrote:
> Hi
>
> In fact, under linux with "return address" and file "/proc/self/maps",
> we can give unique id for every comparison.
Yes, it's doable. But you expressed worries about performance hit of
merging callbacks for different sizes. Mapping pc + i
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
19 matches
Mail list logo
