From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4436 invoked by alias); 29 Sep 2004 22:06:08 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 4421 invoked from network); 29 Sep 2004 22:06:06 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 29 Sep 2004 22:06:06 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8TM66Hn029549; Wed, 29 Sep 2004 18:06:06 -0400 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8TM66r08322; Wed, 29 Sep 2004 18:06:06 -0400 Received: from touchme.toronto.redhat.com (IDENT:postfix@touchme.toronto.redhat.com [172.16.14.9]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id i8TM5v1l010192; Wed, 29 Sep 2004 18:06:05 -0400 Received: from toenail.toronto.redhat.com (toenail.toronto.redhat.com [172.16.14.211]) by touchme.toronto.redhat.com (Postfix) with ESMTP id A04EF8003BB; Wed, 29 Sep 2004 18:05:57 -0400 (EDT) Received: from toenail.toronto.redhat.com (localhost.localdomain [127.0.0.1]) by toenail.toronto.redhat.com (8.12.10/8.12.5) with ESMTP id i8TM5vBY014172; Wed, 29 Sep 2004 18:05:57 -0400 Received: (from fche@localhost) by toenail.toronto.redhat.com (8.12.10/8.12.10/Submit) id i8TM5u58014168; Wed, 29 Sep 2004 18:05:56 -0400 X-Authentication-Warning: toenail.toronto.redhat.com: fche set sender to fche@redhat.com using -f To: "Doug Graham" Cc: gcc@gcc.gnu.org Subject: Re: mudflap problem References: <4159BBC2.8010504@home.nl> <20040929205648.GT4804@nortelnetworks.com> From: fche@redhat.com (Frank Ch. Eigler) Date: Wed, 29 Sep 2004 23:14:00 -0000 In-Reply-To: <20040929205648.GT4804@nortelnetworks.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Reasonable Discussion) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-09/txt/msg01634.txt.bz2 "Doug Graham" writes: > [...] I'm fairly sure that mudflap doesn't check any pointer arith That's correct - mudflap does not check pointer manipulation, except the final dereference. > so I thought that there would be plenty of cases similar > (but not quite the same) to the one that he is asking about that would not > be caught by mudflap. But then I tried this: > [...] > I thought that since b+16 points to the base of a, mudflap would not > complain about the dereference in foo(). But it did somehow know that > the pointer passed in to foo() was derived from 'b' rather than 'a'. I believe this is an optimization artifact. With "-O2", the declaration of "a" is marked somehow as unused (it is), and libmudflap does not get a startup-time registration call for it. Thus b[16] is checked and is found to refer to an invalid address. You may find running programs with env MUDFLAP_OPTIONS="-trace-calls" will clarify the actual behavior of the code. > How did mudflap know in foo(), without using fat pointers, that the > pointer was derived from 'b'? It didn't. > Herman's bounds-checking patches can catch this as well, but they do > so by adding some pad bytes between 'a' and 'b', so that b+16 does > not point to anything that can be legally dereferenced. Adding some padding between static objects would help mudflap catch such off-by-one (but not off-by-many) accesses in the same way. > [...] My original intent was to suggest that maybe mudflap could > (perhaps optionally) check pointer arithmetic as well [...] It might help catch more problems earlier and with more specificity, but this would require a lot more instrumentation code to be run, and thus slow down execution even more. - FChE