> Patches should be posted to gcc-patches.
>From pr59897
--- ../_clean/gcc/testsuite/c-c++-common/asan/use-after-return-1.c
2014-01-09 10:14:04.0 +0100
+++ gcc/testsuite/c-c++-common/asan/use-after-return-1.c2014-01-09
15:51:04.0 +0100
@@ -48,6 +48,6 @@ int main(int
On Tue, Jan 21, 2014 at 04:14:23PM +0400, Maxim Ostapenko wrote:
> > On x86_64-apple-darwin1* the test
> c-c++-common/asan/use-after-return-1.c (new at r206458) fails.
>
> Yes, unfortunately I forgot about this. The patch makes sense.
>
> Should I commit it to fix this bug?
Patches should be pos
> On x86_64-apple-darwin1* the test
c-c++-common/asan/use-after-return-1.c (new at r206458) fails.
Yes, unfortunately I forgot about this. The patch makes sense.
Should I commit it to fix this bug?
-Maxim
> Apologies for the delay. The patch is OK.
Thanks. Committed revision 206875.
Thank you,
Tatiana Udalova
> Thanks, commited in 206458 without c-c++-common/asan/no-asan-stack.c
> testfile. ...
This caused http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59897.
TIA
Dominique
Apologies for the delay. The patch is OK.
On Thu, Jan 16, 2014 at 12:59 AM, Tatiana Udalova wrote:
> Ping!
>
> Thank you,
> Tatiana Udalova
>
>
> --
>
> Hello,
>
> I have reproduced the problem with mklog mentioned by Jakub:
>
>> In my experience mklog is pretty much useless, e.g. if you
Ping!
Thank you,
Tatiana Udalova
--
Hello,
I have reproduced the problem with mklog mentioned by Jakub:
> In my experience mklog is pretty much useless, e.g. if you add a new
> function, it will list the previous function as being modified rather
> than the new one, etc.
My focus w
On 01/10/2014 12:36 PM, Jakub Jelinek wrote:
On Fri, Jan 10, 2014 at 12:34:49PM +0400, Maxim Ostapenko wrote:
Thanks, got it. Is it OK now?
Yes, thanks.
2014-01-10 Max Ostapenko
* c-c++-common/asan/no-asan-stack.c: New test.
Jakub
Commited in 206515.
-Maxim.
On Fri, Jan 10, 2014 at 12:34:49PM +0400, Maxim Ostapenko wrote:
> Thanks, got it. Is it OK now?
Yes, thanks.
> 2014-01-10 Max Ostapenko
>
> * c-c++-common/asan/no-asan-stack.c: New test.
Jakub
If you want to limit to x86_64-linux only, please do:
target { { i?86-*-linux* x86_64-*-linux* } && lp64 }
instead. Also, what advantages do you see for trying to assemble
the result? If you instead just do dg-do compile, you can drop -save-temps
from dg-options and /* { dg-final { cleanup-saved
On Fri, Jan 10, 2014 at 11:49:43AM +0400, Maxim Ostapenko wrote:
> 2014-01-10 Max Ostapenko
>
> * c-c++-common/asan/no-asan-stack.c: New test.
> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/asan/no-asan-stack.c
> @@ -0,0 +1,17 @@
> +/* { dg-do assemble { target { x86_64-unknown-linux
Hi!
>>> * c-c++-common/asan/no-asan-stack.c (this triggers read overflow
>>> because we haven't found a cross-platform way to grep for stack
>>> redzones instrumentation)
>>
>> I'd prefer no test in that case, or just some semi-platform specific
test
>> (scan that the 0x41b58ab3 constant doesn't
> I hacked a simple addition to mklog which skips unchanged functions
> in diff-log while adding function names to the final ChangeLog.
>
> New mklog results were verified by testsuite which compares reference
> ChangeLogs of patches from gcc trunk with logs generated by mklog.
>
> Patched mklog c
Hello,
I have reproduced the problem with mklog mentioned by Jakub:
> In my experience mklog is pretty much useless, e.g. if you add a new
> function, it will list the previous function as being modified rather
> than the new one, etc.
My focus was on functions from headers of diff-log chunks.
Hi!
>> * c-c++-common/asan/no-asan-stack.c (this triggers read overflow
>> because we haven't found a cross-platform way to grep for stack
>> redzones instrumentation)
> I'd prefer no test in that case, or just some semi-platform specific
test
> (scan that the 0x41b58ab3 constant doesn't appear
Hi!
On Fri, Dec 27, 2013 at 03:06:06PM +0400, Yury Gribov wrote:
> We did exactly this for majority of tests except for
Ah, sorry, I saw one test and didn't check carefully the rest of them.
> * c-c++-common/asan/use-after-return-1.c (back-ported from Clang, no UB)
Well, it is still UB, but one
Jakub wrote:
IMNSHO it is far better to just change those
tests into compile time tests and verify assembly using dg-final
scan-assembler.
We did exactly this for majority of tests except for
* c-c++-common/asan/use-after-return-1.c (back-ported from Clang, no UB)
* c-c++-common/asan/no-asan-st
On Tue, Dec 24, 2013 at 02:10:57PM +0400, Maxim Ostapenko wrote:
> >As for the tests, I'm afraid I don't like them at all.
> >If anything, it ought to be dg-do compile tests where you say
> >scan assembly or some dump, but having runtime testcases that
> >trigger undefined behavior that isn't detec
On 12/19/2013 04:27 PM, Jakub Jelinek wrote:
On Thu, Dec 19, 2013 at 04:02:47PM +0400, Maxim Ostapenko wrote:
Sorry, ChangeLog and patch, of course.
2013-12-19 Max Ostapenko
* cfgexpand.c (expand_stack_vars): Optionally disable asan stack
protection.
Too long lines in ChangeLog, w
Diego wrote:
How about this then? Updated mklog now adds 'New file'/'New
test'/'Remove' when necessary.
This is OK. Thanks.
Submitted in r206175.
Let me know if you have ideas on improving the current script. I think
it may make sense to address Jakub's complaint about redundant functions:
On 20/12/2013, 07:08 , Yury Gribov wrote:
Ultimately, mklog ought to write the ChangeLog itself.
We get rid of that headache, at least.
How about this then? Updated mklog now adds 'New file'/'New
test'/'Remove' when necessary.
I did some tests with unified/context-diffed SVN and git and it w
Ultimately, mklog ought to write the ChangeLog itself.
We get rid of that headache, at least.
How about this then? Updated mklog now adds 'New file'/'New
test'/'Remove' when necessary.
I did some tests with unified/context-diffed SVN and git and it worked
as expected. I can do more testing i
The patch is OK. Feel free to submit now, if you want.
Thanks. Done in r206116.
-Y
On Thu, Dec 19, 2013 at 9:33 AM, Yury Gribov wrote:
> Frankly in my experience Perl with `use warnings' and `use strict' isn't
> that bad. We could just as well massage existing script.
I suppose.
> Got it. Attached new version of script and ChangeLog entry. Will submit
> tomorrow if noone obje
On 12/19/2013 05:47 PM, Diego Novillo wrote:
The patch is fine (some tweaks below).
If someone volunteers to re-write it in Python,
I think it would make it easier to keep extending.
Frankly in my experience Perl with `use warnings' and `use strict' isn't
that bad. We could just as well massag
On Thu, Dec 19, 2013 at 8:04 AM, Yury Gribov wrote:
> On 12/19/2013 04:17 PM, Yury Gribov wrote:
>>> In my experience mklog is pretty much useless, e.g. if you
>>> add a new function, it will list the previous function as being modified
>>> rather than the new one, etc.
>>
>> In my experience it p
On 12/19/2013 04:17 PM, Yury Gribov wrote:
>> In my experience mklog is pretty much useless, e.g. if you
>> add a new function, it will list the previous function as being modified
>> rather than the new one, etc.
>
> In my experience it prints both the old and the new one. If that's a
> problem w
On Thu, Dec 19, 2013 at 04:02:47PM +0400, Maxim Ostapenko wrote:
> Sorry, ChangeLog and patch, of course.
> 2013-12-19 Max Ostapenko
>
> * cfgexpand.c (expand_stack_vars): Optionally disable asan stack
> protection.
Too long lines in ChangeLog, wrap to 80 columns.
> (expand_used
In my experience mklog is pretty much useless, e.g. if you
add a new function, it will list the previous function as being modified
rather than the new one, etc.
In my experience it prints both the old and the new one. If that's a
problem we could probably fix it (I mean I can volunteer).
Her
Sorry, ChangeLog and patch, of course.
-Maxim.
2013-12-19 Max Ostapenko
* cfgexpand.c (expand_stack_vars): Optionally disable asan stack protection.
(expand_used_vars): Likewise.
(partition_stack_vars): Likewise.
* asan.c (asan_emit_stack_protection): Optionally disable after return stack
2013-12-18 Max Ostapenko
* gcc/asan.c (asan_emit_stack_protection): Optionally disable
stack protection.
(instrument_derefs): Optionally disable memory access
instrumentation.
(instrument_mem_region_access): Likewise.
(instrument_strlen_call): Likewise.
(asan_finish_file)
On Thu, Dec 19, 2013 at 02:28:11PM +0400, Yury Gribov wrote:
> > No gcc/ prefixes in ChangeLog entries.
>
> Should we update contrib/mklog then?
In my experience mklog is pretty much useless, e.g. if you
add a new function, it will list the previous function as being modified
rather than the new
> No gcc/ prefixes in ChangeLog entries.
Should we update contrib/mklog then?
-Y
On Wed, Dec 18, 2013 at 03:35:35PM +0400, Maxim Ostapenko wrote:
> 2013-12-18 Max Ostapenko
>
> * gcc/asan.c (asan_emit_stack_protection): Optionally disable stack
> protection.
> (instrument_derefs): Optionally disable memory access instrumentation.
> (instrument_mem_region_
Hi all,
On 12/06/2013 05:32 PM, Yury Gribov wrote:
So it looks like people are generally ok with
* --param asan-instrument-reads=0/1
* --param asan-instrument-writes=0/1
* --param asan-stack=0/1
* --param asan-globals=0/1
I've implemented these options. Tested on x86_64.
* --param asan-memint
>
> Agreed. I guess our main question is whether such mechanism is really needed
> by developers.
We use the blacklist:
- with asan init-order-checker to disable checking some specific
globals by their type name ("bening" true positive)
- with msan to suppress true benign reports from zlib's defla
Jakub wrote:
> You can still -include some header file from the command line and put the
> attributes in there or similar.
True although this probably won't work with C++ methods.
> The blacklist is really terribly ugly hack,
> which can't work reliably. What do you do for anonymous namespaces?
On Tue, Dec 10, 2013 at 12:10 PM, Jakub Jelinek wrote:
> On Tue, Dec 10, 2013 at 12:06:55PM +0400, Yury Gribov wrote:
>> > I'm strongly against the blacklist,
>> > that is not the way things are done in GCC,
>> > you have corresponding attribute to mark functions
>> > you don't want to instrument,
On Tue, Dec 10, 2013 at 12:06:55PM +0400, Yury Gribov wrote:
> > I'm strongly against the blacklist,
> > that is not the way things are done in GCC,
> > you have corresponding attribute to mark functions
> > you don't want to instrument, people can macroize that with
> > __typeof (symbol) symbol __
> I'm strongly against the blacklist,
> that is not the way things are done in GCC,
> you have corresponding attribute to mark functions
> you don't want to instrument, people can macroize that with
> __typeof (symbol) symbol __attribute__((__no_sanitize_address__));
> But in any case, you mark it
On Fri, Dec 06, 2013 at 04:16:04PM +0100, Jakub Jelinek wrote:
> On Fri, Dec 06, 2013 at 04:10:31PM +0100, Ondřej Bílka wrote:
> > Currently this code with sanitize=address gets expanded
> >
> > int foo(char *x, char *y, int i)
> > {
> > x[i] = y[i];
> > }
> >
> > to
> >
> > snip
> > movq
On Fri, Dec 06, 2013 at 04:10:31PM +0100, Ondřej Bílka wrote:
> Currently this code with sanitize=address gets expanded
>
> int foo(char *x, char *y, int i)
> {
> x[i] = y[i];
> }
>
> to
>
> snip
> movq%rsi, %rax
> movq%rsi, %rdx
> shrq$3, %rax
> andl
On Fri, Dec 06, 2013 at 01:34:43PM +0100, Jakub Jelinek wrote:
> On Fri, Dec 06, 2013 at 01:32:42PM +0100, Ondřej Bílka wrote:
> > On second though besides of decreasing of code size there is no reason
> > to complicate compilation for these features. A more flexible way is add
> > environment vari
Konstantin wrote:
> My comment about "don't implement them" was only about the flags
> that change shadow offset & scale
Ah, I see. I didn't mention them in the first place so I got puzzled.
So it looks like people are generally ok with
* --param asan-instrument-reads=0/1
* --param asan-instrume
On Fri, Dec 6, 2013 at 5:10 PM, Yury Gribov wrote:
> Konstantin wrote:
>> Can you have a target specific config for the particular target
>> that will have its own shadow offset & scale?
>
> Yes, we have this but I don't see how this can help with code
> instrumentation overheads.
My comment about
Konstantin wrote:
> Can you have a target specific config for the particular target
> that will have its own shadow offset & scale?
Yes, we have this but I don't see how this can help with code
instrumentation overheads.
-Y
On Fri, Dec 6, 2013 at 4:39 PM, Yury Gribov wrote:
> Konstantin wrote:
>
>> Jakub wrote:
>>> I'm strongly against the blacklist,
>> I don't like it either. We were forced to implement it by reality.
>> ...
>
>> imagine third-party code which you can build but can not change
>
> Same situation here
Konstantin wrote:
> Jakub wrote:
>> I'm strongly against the blacklist,
> I don't like it either. We were forced to implement it by reality.
> ...
> imagine third-party code which you can build but can not change
Same situation here. Reality is that Asan is often thrown at huge (I
mean several M
On Fri, Dec 06, 2013 at 01:32:42PM +0100, Ondřej Bílka wrote:
> On second though besides of decreasing of code size there is no reason
> to complicate compilation for these features. A more flexible way is add
> environment variable that will disable these at runtime.
That is not possible, the ins
On Fri, Dec 06, 2013 at 01:09:29PM +0100, Jakub Jelinek wrote:
> On Fri, Dec 06, 2013 at 03:28:50PM +0400, Yury Gribov wrote:
> > Hi all,
> >
> > GCC version of Asan currently lacks options for detailed control
> > over code instrumentation. These are not usually necessary but for
> > embedded sys
On Fri, Dec 6, 2013 at 4:09 PM, Jakub Jelinek wrote:
> On Fri, Dec 06, 2013 at 03:28:50PM +0400, Yury Gribov wrote:
>> Hi all,
>>
>> GCC version of Asan currently lacks options for detailed control
>> over code instrumentation. These are not usually necessary but for
>> embedded systems with scarc
atches , Viacheslav Garbuzov
> , Max Ostapenko
> Subject: Re: RFC Asan instrumentation control
>
>
> On 12/06/2013 03:55 PM, Yury Gribov wrote:
> Konstantin Serebryany wrote:
>> only -asan-stack and -asan-globals affect the memory overhead
>
> But disabling code also counts. -a
On Fri, Dec 06, 2013 at 03:28:50PM +0400, Yury Gribov wrote:
> Hi all,
>
> GCC version of Asan currently lacks options for detailed control
> over code instrumentation. These are not usually necessary but for
> embedded systems with scarce system resources Asan memory overhead
> of 2x-3x may often
> big code size reduction
I meant to say "instrumented code size reduction"...
-Y
---
From: Yury Gribov
Sent: Friday, December 06, 2013 3:55PM
To: Konstantin Serebryany
Cc: GCC Patches , Viacheslav Garbuzov
, Max Ostapenko
Subject:
Konstantin Serebryany wrote:
> only -asan-stack and -asan-globals affect the memory overhead
But disabling code also counts. -asan-instrument-reads=0 may result in
big code size reduction (I'd say over 50%).
-Y
On Fri, Dec 6, 2013 at 3:28 PM, Yury Gribov wrote:
> Hi all,
>
> GCC version of Asan currently lacks options for detailed control over code
> instrumentation. These are not usually necessary but for embedded systems
> with scarce system resources Asan memory overhead of 2x-3x may often be
> unacce
On Fri, Dec 06, 2013 at 03:28:50PM +0400, Yury Gribov wrote:
> Hi all,
>
> GCC version of Asan currently lacks options for detailed control
> over code instrumentation. These are not usually necessary but for
> embedded systems with scarce system resources Asan memory overhead
> of 2x-3x may often
Hi all,
GCC version of Asan currently lacks options for detailed control over
code instrumentation. These are not usually necessary but for embedded
systems with scarce system resources Asan memory overhead of 2x-3x may
often be unacceptable.
It seems that LLVM provides some options to allow
58 matches
Mail list logo
