This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[PATCH] Fix mudflap failures with -static
- From: Ulrich Weigand <weigand at i1 dot informatik dot uni-erlangen dot de>
- To: gcc-patches at gcc dot gnu dot org
- Date: Fri, 16 Jul 2004 21:19:57 +0200 (CEST)
- Subject: [PATCH] Fix mudflap failures with -static
Hello,
now that glibc's backtrace () is fixed on s390, I'm still getting
many failures for statically linked mudflap test cases. But this
appears to be a bug in libmudflap. What happens is:
During '_init' processing of constructors, sometime before __mf_init,
__register_frame_info_bases is called and allocates some memory.
As we're before __mf_init, this allocation isn't registered anywhere.
During '_exit' processing of destructors, sometime after __mf_fini,
__deregister_frame_info_bases is then called and frees that memory.
This call to free is trapped by mudflap, and since it doesn't have
a record of that allocation, it detects a violation.
(This only happens with statically linked libmudflag; a dynamically
linked libmudflag would already have been unloaded at this point,
and thus the call 'free' wouldn't be instrumented any more.)
I guess one possible fix would be to simply stop detecting violations
after __mf_fini has been called. This is implemented by the following
patch, which fixes all mudflap testcases on s390-ibm-linux and
s390x-ibm-linux (except libmudflap.cth/pass40-frag.c which sometimes
hangs).
OK?
Bye,
Ulrich
ChangeLog:
* mf-runtime.c (__mf_fini): Set mudflap_mode to mode_nop in
the statically linked case.
Index: libmudflap/mf-runtime.c
===================================================================
RCS file: /cvs/gcc/gcc/libmudflap/mf-runtime.c,v
retrieving revision 1.10
diff -c -p -r1.10 mf-runtime.c
*** libmudflap/mf-runtime.c 15 Jul 2004 17:33:23 -0000 1.10
--- libmudflap/mf-runtime.c 16 Jul 2004 18:32:31 -0000
*************** void __mf_fini ()
*** 716,721 ****
--- 716,727 ----
{
TRACE ("__mf_fini\n");
__mfu_report ();
+
+ #ifndef PIC
+ /* Since we didn't populate the tree for allocations in constructors
+ before __mf_init, we cannot check destructors after __mf_fini. */
+ __mf_opts.mudflap_mode = mode_nop;
+ #endif
}
--
Dr. Ulrich Weigand
weigand@informatik.uni-erlangen.de