This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa libmudflap long] multithreading fixes, build reorg, testsuite extensions


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]