On 12/04/2014 10:10 PM, Dmitry Vyukov wrote:
> On Wed, Dec 3, 2014 at 9:19 AM, Andrey Ryabinin
> wrote:
>> On 12/02/2014 08:56 PM, Dmitry Vyukov wrote:
>>> Hi,
>>>
>>> The following patch adds support for instrumentation of globals for
>>> Linux
On 12/02/2014 08:56 PM, Dmitry Vyukov wrote:
> Hi,
>
> The following patch adds support for instrumentation of globals for
> Linux kernel (-fsanitize=kernel-address). Kernel only supports
> constructors with default priority, but the rest works fine.
>
> OK for trunk?
>
I know this is too late
On 10/23/2014 02:38 PM, Jakub Jelinek wrote:
> On Thu, Oct 23, 2014 at 02:33:42PM +0400, Yury Gribov wrote:
>> Actually this is a historical artifact. If inlining proves to be
>> significantly faster, they may want to switch.
>
> Ok.
>
>>> So, at that point you can include your ugly hacks in __a
On 10/23/2014 02:00 PM, Jakub Jelinek wrote:
> On Thu, Oct 23, 2014 at 11:55:32AM +0200, Jakub Jelinek wrote:
>> On Thu, Oct 23, 2014 at 01:51:12PM +0400, Andrey Ryabinin wrote:
>>> IMO we don't need different versions of __asan_load* and
>>> __asan_load*_no
On 10/23/2014 01:55 PM, Jakub Jelinek wrote:
> On Thu, Oct 23, 2014 at 01:51:12PM +0400, Andrey Ryabinin wrote:
>> IMO we don't need different versions of __asan_load* and
>> __asan_load*_noabort, because
>> -fno-sanitize-recover=kernel-address will never work with
On 10/23/2014 11:28 AM, Yury Gribov wrote:
> On 10/23/2014 11:13 AM, Jakub Jelinek wrote:
>> On Thu, Oct 23, 2014 at 11:11:29AM +0400, Yury Gribov wrote:
>>> Hi all,
>>>
>>> On 09/29/2014 09:21 PM, Yury Gribov wrote:
>> This patch enables -fsanitize-recover for KASan by default. This causes
>>>
On 09/05/2014 10:54 AM, Yury Gribov wrote:
> Hi all,
>
> This patch enables -fsanitize-recover for KASan by default. This causes KASan
> to continue execution after error in case of inline instrumentation. This
> feature is needed because
> - reports during early bootstrap won't even be printed
On 07/22/14 14:30, Yury Gribov wrote:
>>> It is required for Kernel AddressSanitizer, as the shadow offset is
>>> not known at the compile time,
>>
>> To get shadow offset this patch uses function __asan_get_shadow_ptr.
>> Wouldn't be more effective just to read variable instead of function call?
>
On 07/21/14 23:00, Alexey Preobrazhensky wrote:
> Hi all,
>
> This patch adds support for non-fixed shadow in asan stack instrumentation.
>
> It is required for Kernel AddressSanitizer, as the shadow offset is
> not known at the compile time,
To get shadow offset this patch uses function __asan_
