[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program

["ppluzhnikov at charter dot net" <gcc-bugzilla at gcc dot gnu dot org>]

------- 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 <ctype.h>

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