On Thu, Dec 13, 2012 at 02:22:52PM +0400, Konstantin Serebryany wrote:
> I've added two flags, both on by default for now.
>
> // Use fast (frame-pointer-based) unwinder on fatal errors (if available).
> bool fast_unwind_on_fatal;
> // Use fast (frame-pointer-based) unwinder on malloc/free (
I've added two flags, both on by default for now.
// Use fast (frame-pointer-based) unwinder on fatal errors (if available).
bool fast_unwind_on_fatal;
// Use fast (frame-pointer-based) unwinder on malloc/free (if available).
bool fast_unwind_on_malloc;
% clang -fsanitize=address -g
~/ll
On Thu, Dec 13, 2012 at 11:44:12AM +0400, Konstantin Serebryany wrote:
> We are discussing it from time to time.
> Sometimes, if e.g. an error happens inside a qsort callback,
> the fp-based unwinder fails to unwind through libc, while _Unwind would work.
>
> I was opposed to this sometime ago bec
On Thu, Dec 13, 2012 at 1:30 AM, Jakub Jelinek wrote:
> On Wed, Dec 12, 2012 at 10:16:49PM +0100, Dodji Seketeli wrote:
>> Independently of this review, I think it's be interesting to hear
>> Kostya's voice on:
>>
>> Jakub Jelinek writes:
>>
>> > 2) In large-func-test-1.C, I had to stop matching
Hello,
Independently of this review, I think it's be interesting to hear
Kostya's voice on:
Jakub Jelinek writes:
> 2) In large-func-test-1.C, I had to stop matching the backtrace after
> _Znw[jm], because libasan is using the fast but inaccurate backtrace,
> and while the tests can be easily t
On Wed, Dec 12, 2012 at 10:16:49PM +0100, Dodji Seketeli wrote:
> Independently of this review, I think it's be interesting to hear
> Kostya's voice on:
>
> Jakub Jelinek writes:
>
> > 2) In large-func-test-1.C, I had to stop matching the backtrace after
> > _Znw[jm], because libasan is using th
Hi!
On Tue, Dec 04, 2012 at 10:00:35AM -0800, Wei Mi wrote:
> I updated the patch according to the comments. Please take a look. Thanks.
Rather than several further rounds of review, let me post an incremental
patch on top of yours. Your patch seems to be incomplete BTW, that
asan-special.exp an
On Tue, Dec 04, 2012 at 11:22:40AM +0400, Kostya Serebryany wrote:
> Please note that tsan has 20+ more tests like this
> (projects/compiler-rt/lib/tsan/lit_tests) and asan will be getting more
> such tests too
> (mostly for the new features such as use-after-return, use-after-scope,
> global-init)
On Dec 3, 2012, at 11:36 AM, Jakub Jelinek wrote:
> The env vars are used by the target libs when running the test executable.
> So, are you suggesting we name it dg-set-target-env-var instead of
> dg-set-env-var, so that in the future we can also have
> dg-set-{host,build}-env-var?
Yes. The set
On Mon, Dec 03, 2012 at 10:32:52AM -0800, Wei Mi wrote:
> Jakub, thank you for your so detailed comments! I will fix them
> according to your comments. About the lto options, llvm test does't
> include it too so I skipped it in torture options. Is it because most
> cases we only use asan under O1/O
On Mon, Dec 03, 2012 at 11:09:07AM -0800, Mike Stump wrote:
> On Dec 3, 2012, at 3:00 AM, Jakub Jelinek wrote:
> > Mike, CCing you especially on the proposed lib/gcc-dg.exp dg-env-var
> > changes and I have one question about cleanup of files (file delete
> > vs. remote_file target (or is that hos
On Dec 3, 2012, at 3:00 AM, Jakub Jelinek wrote:
> Mike, CCing you especially on the proposed lib/gcc-dg.exp dg-env-var
> changes and I have one question about cleanup of files (file delete
> vs. remote_file target (or is that host or build) delete).
> But of course if you could eyeball the rest a
On Mon, Dec 3, 2012 at 10:32 PM, Wei Mi wrote:
> Hi,
>
> Jakub, thank you for your so detailed comments! I will fix them
> according to your comments. About the lto options, llvm test does't
> include it too so I skipped it in torture options. Is it because most
> cases we only use asan under O1/O
Hi,
Jakub, thank you for your so detailed comments! I will fix them
according to your comments. About the lto options, llvm test does't
include it too so I skipped it in torture options. Is it because most
cases we only use asan under O1/O2? Kostya, could you tell us is there
any reason to not tes
Hi!
Mike, CCing you especially on the proposed lib/gcc-dg.exp dg-env-var
changes and I have one question about cleanup of files (file delete
vs. remote_file target (or is that host or build) delete).
But of course if you could eyeball the rest and comment, I'd be even happier.
On Fri, Nov 30, 201
Looks good.
Long term the fact that we need to completely fork these tests makes me sad.
I'd really love to see a way to make them compiler-neutral.
All we need is to mock FileCheck (or put it into libsanitizer/aux somehow).
Ideas?
--kcc
On Sat, Dec 1, 2012 at 12:35 AM, Wei Mi wrote:
> Thanks
On Wed, Nov 28, 2012 at 3:24 PM, Jakub Jelinek wrote:
> On Wed, Nov 28, 2012 at 12:03:27PM +0100, Jakub Jelinek wrote:
>> Then the test would be run once without ASAN_DIE_IF in environment (or =0),
>> that would produce output full of
>> EXPECT_DEATH1 AddressSanitizer:.*heap-use-after-free EXPECT_
On Wed, Nov 28, 2012 at 12:03:27PM +0100, Jakub Jelinek wrote:
> Then the test would be run once without ASAN_DIE_IF in environment (or =0),
> that would produce output full of
> EXPECT_DEATH1 AddressSanitizer:.*heap-use-after-free EXPECT_DEATHEND1
> ...
> which tcl could parse, and figure from it
That's a bit scary (and will be slower than with gtest).
But if we can limit the changes by replacing
asan/tests/asan_test_config.h (and maybe some minimal other changes)
that may work.
--kcc
On Wed, Nov 28, 2012 at 3:03 PM, Jakub Jelinek wrote:
> On Wed, Nov 28, 2012 at 02:40:55PM +0400, Konsta
On Wed, Nov 28, 2012 at 02:40:55PM +0400, Konstantin Serebryany wrote:
> I fully agree about "minimal testsuite".
> But, for example, porting the asan's gtest test (2+ KLOC) to another
> harness is probably too much.
Depends on how significant changes to the test body are actually needed,
and if w
On Wed, Nov 28, 2012 at 2:24 PM, Jakub Jelinek wrote:
> On Wed, Nov 28, 2012 at 02:10:05PM +0400, Konstantin Serebryany wrote:
>> I'd like to understand our long-term strategy wrt the asan/tsan tests in gcc.
>> Most of the tests we have today are not specific to the compiler and
>> so can potentia
On Wed, Nov 28, 2012 at 02:10:05PM +0400, Konstantin Serebryany wrote:
> I'd like to understand our long-term strategy wrt the asan/tsan tests in gcc.
> Most of the tests we have today are not specific to the compiler and
> so can potentially be used with any compiler.
> The problem is the testing
Hi!
On Wed, Nov 28, 2012 at 01:15:20AM -0800, Wei Mi wrote:
> I try to migrate the left asan lit-tests from llvm (class3). This is a
> preliminary version patch. Please forgive it has many mistakes.
Thanks for working on it.
> A known problems: I hardcoded -m32 in (set link_flags
> "[asan_link_f
I'd like to understand our long-term strategy wrt the asan/tsan tests in gcc.
Most of the tests we have today are not specific to the compiler and
so can potentially be used with any compiler.
The problem is the testing harness (FileCheck/gtest vs dejagnu).
I understand that using alien testing har
24 matches
Mail list logo
