------- 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
