------- Comment #34 from f dot knauf at mmkf dot de 2009-05-07 16:30 -------
I can confirm the behaviour for sparc-sun-solaris2.8, the first program
mentioned in the last comment complains as follows:
*******
mudflap violation 1 (check/write): time=1241712982.495997 ptr=ffbefac4 size=4
pc=ff288ac8
location=`/usr/local/lib/gcc/sparc-sun-solaris2.8/4.4.0/../../../../sparc-sun-solaris2.8/include/c++/4.4.0/bits/stl_tree.h:171:20
(std::_Rb_tree_iterator<std::pair<const int, int> >::_Rb_tree_iterator)'
[0xff2876f0]
Nearby object 1: checked region begins 1B after and ends 4B after
mudflap object af548:
name=`/usr/local/lib/gcc/sparc-sun-solaris2.8/4.4.0/../../../../sparc-sun-solaris2.8/include/c++/4.4.0/bits/stl_map.h:539:23
(std::map<int, int, std::less<int>, std::allocator<std::pair<const int, int> >
>::insert) std::_Rb_tree_iterator<std::pair<const int, int> > __position'
bounds=[ffbefac0,ffbefac3] size=4 area=stack check=1r/0w liveness=1
alloc time=1241712982.495900 pc=ff2881a4
Nearby object 2: checked region begins 4B before and ends 1B before
mudflap object af440:
name=`/usr/local/lib/gcc/sparc-sun-solaris2.8/4.4.0/../../../../sparc-sun-solaris2.8/include/c++/4.4.0/bits/stl_map.h:447:11
(std::map<int, int, std::less<int>, std::allocator<std::pair<const int, int> >
>::operator[]) std::_Rb_tree_iterator<std::pair<const int, int> > __i'
bounds=[ffbefac8,ffbefacb] size=4 area=stack check=0r/1w liveness=1
alloc time=1241712982.495875 pc=ff2881a4
Nearby object 3: checked region begins 4B before and ends 1B before
mudflap dead object adc00:
name=`/usr/local/lib/gcc/sparc-sun-solaris2.8/4.4.0/../../../../sparc-sun-solaris2.8/include/c++/4.4.0/bits/stl_map.h:447:11
(std::map<int, int, std::less<int>, std::allocator<std::pair<const int, int> >
>::operator[]) std::_Rb_tree_iterator<std::pair<const int, int> > __i'
bounds=[ffbefac8,ffbefacb] size=4 area=stack check=0r/1w liveness=1
alloc time=1241712982.495593 pc=ff2881a4
dealloc time=1241712982.495861 pc=ff287d58
number of nearby objects: 3
I compiled it with a gcc 4.4.0 cross compiler from i486-linux-gnu to
sparc-sun-solaris2.8 (sparcv8), compiler options -fmudflap -lmudflap -lsocket
(the last one being necessary to link mudflap). I had to remove the getmntent
wrapper from the mudflap library because solaris 2.8 uses an interface
different from the one gcc expects. Other than that, the gcc sources the
compiler was built from were unchanged.
As on x86, the same program compiled with the same options plus -m64 (i.e., for
sparcv9) yields no mudflap errors.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
