This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa libmudflap long] multithreading fixes, build reorg, testsuite extensions
- From: Eyal Lebedinsky <eyal at eyal dot emu dot id dot au>
- To: "Frank Ch. Eigler" <fche at redhat dot com>, gcc list <gcc at gcc dot gnu dot org>
- Date: Sat, 05 Jul 2003 13:45:19 +1000
- Subject: Re: [tree-ssa libmudflap long] multithreading fixes, build reorg, testsuite extensions
- Organization: Eyal at Home
- References: <20030704190945.A5731@redhat.com>
"Frank Ch. Eigler" wrote:
> This omnibus patch includes several distinct changes, all related to
> the problem of debugging multithreading bugs in libmudflap. The key
> piece of it was that a reentrancy-detection state variable had to
> become per-thread rather than global.
I am now running my regression tests to see how it holds. This should
take a few days...
I notice a number of worrying warnings in the build though, like:
/data1/gcc/gcc-mudflap/gcc/xgcc -B/data1/gcc/gcc-mudflap/gcc/
-B/usr/local/gcc-mudflap/i686-pc-linux-gnu/bin/
-B/usr/local/gcc-mudflap/i686-pc-linux-gnu/lib/ -isystem
/usr/local/gcc-mudflap/i686-pc-linux-gnu/include -isystem
/usr/local/gcc-mudflap/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
-I../../../gcc/libmudflap -I. -O2 -g -O2 -Wall -O2 -g -O2 -DWRAP_free -c
../../../gcc/libmudflap/mf-hooks1.c -fPIC -DPIC -o .libs/free-hook.o
../../../gcc/libmudflap/mf-hooks1.c: In function `free':
../../../gcc/libmudflap/mf-hooks1.c:211: warning: `return' with a value,
in function returning void
../../../gcc/libmudflap/mf-hooks1.c:211: warning: `return' with a value,
in function returning void
../../../gcc/libmudflap/mf-hooks1.c:216: warning: too many arguments for
format
and I am not even mentioning implicit func decl and mismatch in
formats which is old news.
BTW, I am still adjusting some wrappers as I go (nothing too big)
and am keeping the latest patch on my web page at
http://users.bigpond.net.au/eyal/
I needed a raw version of MF_VALIDATE_EXTENT which takes a variable
for the context rather than a constant. I noticed that this macro is
not completely safe, and it uses some aruments more than once, thus
risking side-effect repetition - not that I saw any real argument
abuse so far.
A question though: Is it the case that using functions like sprintf()
or strlen() in a wrapper will invoke the REAL rather than the WRAPPED
one? I see no point in wrapping intrumentation code, and I think that
it may also be wrong as objects in the runtime library are not
themselves registered - right?
--
Eyal Lebedinsky (eyal@eyal.emu.id.au) <http://samba.org/eyal/>