From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-436878-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 24631 invoked by alias); 6 Dec 2013 17:05:02 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Received: (qmail 24566 invoked by uid 48); 6 Dec 2013 17:04:58 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug sanitizer/59410] Some tsan tests fail with 4GB RAM
Date: Fri, 06 Dec 2013 17:05:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: sanitizer
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59410-4-INtQkCj4e9@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59410-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59410-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-12/txt/msg00533.txt.bz2

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
What I mean, unlike asan where the shadow memory shift and base is part of the
ABI, in tsan, while performance sensitive, the MemToShadow is still library
implementation detail.  So, I think it shouldn't be that difficult to support
it.
Perhaps have a compilation mode, one most performant where you'd hardcode what
you do right now and just give up if it can't be made to work, and another
slightly slower one where some of the components (I guess the shift can remain
hardcoded, but ored in constant can be variable, and perhaps some other
operation can be added to the function too).  Then during libtsan
initialization it can just see if the default memory layout is viable and
otherwise try some other one.  I thought we've discussed it to some extent
already, but don't remember where exactly.