From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26736 invoked by alias); 15 Nov 2006 01:22:52 -0000 Received: (qmail 26701 invoked by uid 48); 15 Nov 2006 01:22:43 -0000 Date: Wed, 15 Nov 2006 01:22:00 -0000 Message-ID: <20061115012243.26700.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "ppluzhnikov at charter dot net" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-11/txt/msg01337.txt.bz2 List-Id: ------- Comment #26 from ppluzhnikov at charter dot net 2006-11-15 01:22 ------- (In reply to comment 25) Confirmed: using newer glibc: GNU C Library development release version 2.3.5, by Roland McGrath et al. and having rebuilt gcc-4.3-20061104 on it, I do not see violations on make-3.81 Confirmed: the test case from comment 21 still shows 1 violation. --------------------------------------------------------- I also tracked down the violations I see on glibc-2.1.3 Here is the smallest test case: #include int main() { const char *p = "a"; return isblank(*p); } When compiled with '-fmudflap' there are no violations. When compiled with '-fmudflap -D_GNU_SOURCE', there is a violation: ******* mudflap violation 1 (check/read): time=1163551808.269474 ptr=0x3feeb302 size=2 pc=0x3ff0d2fd location=`junk.c:6 (main)' /usr/local/gcc-4.3-20061104/lib/libmudflap.so.0(__mf_check+0x3d) [0x3ff0d2fd] [0x8048850] /usr/local/gcc-4.3-20061104/lib/libmudflap.so.0(__wrap_main+0x49) [0x3ff0cdb9] number of nearby objects: 0 In the first case, isblank() expands to call to isblank(). In the second, it expands into (__ctype_b[(int) ((*p))] & (unsigned short int) _ISblank) And libmudflap (apparently) doesn't understand where __ctype_b is pointing at. In fact, here is reduced test case that shows the exact same problem regardless of glibc version: $ cat junk1.c extern int *array; int main() { return array[0]; } $ cat junk2.c int _array[1]; int *array = _array; $ gcc -g -c junk2.c && gcc -g -fmudflap junk1.c junk2.o -lmudflap \ -Wl,-rpath=/usr/local/gcc-4.3-20061104/lib && ./a.out ******* mudflap violation 1 (check/read): time=1163552372.861362 ptr=0x80c9998 size=4 pc=0xe6d1bd location=`junk1.c:4 (main)' /usr/local/gcc-4.3-20061104/lib/libmudflap.so.0(__mf_check+0x3d) [0xe6d1bd] ./a.out(main+0x84) [0x8048748] /usr/local/gcc-4.3-20061104/lib/libmudflap.so.0(__wrap_main+0x49) [0xe6cc79] Nearby object 1: checked region begins 8B after and ends 11B after mudflap object 0x80ca0f8: name=`__mf_lc_shift' bounds=[0x80c9990,0x80c9990] size=1 area=no-access check=0r/0w liveness=0 alloc time=1163552372.860997 pc=0xe6cc1d Nearby object 2: checked region begins 9B after and ends 12B after mudflap object 0x80ca028: name=`__mf_lookup_cache' bounds=[0x8049990,0x80c998f] size=524288 area=no-access check=0r/0w liveness=0 alloc time=1163552372.860984 pc=0xe6cc1d number of nearby objects: 2 The above violation goes away when I add MUDFLAP_OPTIONS=-heur-start-end, and gmake-3.81 violations go away when I add MUDFLAP_OPTIONS=-heur-proc-map but I had to dig up the original mudflap design article: http://gcc.fyxm.net/summit/2003/mudflap.pdf to figure this out. If you expect your future users to figure this out, I've got a surprise for you: they most likely will not. These heuristics probably should be enabled by default (at least on Linux), or at least *prominently* displayed in the info/man pages. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319