This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Asan/Tsan Unit/Regression testing (was [asan] Emit GIMPLE direclty, small cleanups)
[re-sending so that it gets to the list]
asan's design choice is to hard crash on the first error.
Doing many asan checks in the same process might become too messy too soon.
I wouldn't try to implement it myself.
Playing with longjmp in asan is not the best idea because asan
intercepts longjmp
and in fact it does have some locks around __asan_report_*
That's why we really like the death tests that run every check in a
separate process.
Why depending on gtest is bad?
--kcc
On Fri, Nov 9, 2012 at 11:16 AM, Jakub Jelinek <jakub@redhat.com> wrote:
>
> On Fri, Nov 09, 2012 at 08:13:12PM +0100, Jakub Jelinek wrote:
> > On Fri, Nov 09, 2012 at 11:05:37AM -0800, Wei Mi wrote:
> > > gtest integrate multiple tests into the same file with each test being
> > > a single line check. I cannot think out a method to migrate it to
> > > dejagnu without using gtest, except splitting a single gtest file to
> > > multiple files with each file per test. asan has about 130 tests so
> > > have to write 130 files which will be a doable but painful task.
> >
> > See the glibc _FORTIFY_SOURCE check I've referenced, there it is 3 lines
> > per test expected to crash, but could be done in a single macro too.
> > If the failure can be intercepted, it can be done in a single process
> > (e.g.
> > SIGABRT can, _exit can't that easily), otherwise perhaps say way to skip
> > previous tests and communicate with dejagnu how many times it should run
> > the
> > executable.
>
> And quick grep shows that one can call __sanitizer::SetDieCallback
> and supposedly, if ASAN doesn't hold any locks when it calls Die() that
> would prevent it from functioning further, we can just longjmp out from
> the
> callback.
>
> Jakub