From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19324 invoked by alias); 30 Jan 2013 14:42:00 -0000 Received: (qmail 17667 invoked by uid 48); 30 Jan 2013 14:41:20 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin Date: Wed, 30 Jan 2013 14:42: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-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-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2013-01/txt/msg02754.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #13 from Jakub Jelinek 2013-01-30 14:41:14 UTC --- (In reply to comment #12) > This one is a necessary one. > asan_finish_file inserts __asan_init into the array of constructors (aka > __mod_init_func section). But for some reason it is inserted at the end of that > array, while the constructors are being executed from the start of the array at > program startup. That's why the program crashes (because it's trying to execute > some instrumented code that accesses the shadow memory, which isn't mapped > yet), and the real question is how do we put the new constructor first provided > that the ctor priorities do not work well on Darwin. Guess if Darwin ignores priority, then the reason for that is that asan_finish_file which adds the ctor is called very late during compilation (and has to be, otherwise it e.g. wouldn't know if it is needed at all and what globals need to be registered). And the bug is clear, config/darwin* shouldn't ignore the priority. If the object format is lame enough and doesn't support priorities, at least the routines should ensure the right priority ordering within the same compilation unit (whether by not emitting anything right away and queueing it up for emit very late, sorted according to the priority, or something else, I don't care).