This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: libmudflap and emutls question
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: Jie Zhang <jie dot zhang at analog dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Sun, 04 Jan 2009 10:42:38 -0500
- Subject: Re: libmudflap and emutls question
- References: <49608DDA.8050105@analog.com>
Jie Zhang <jie.zhang@analog.com> writes:
> I encountered a recursive call problem between libmudflap and emutls
> when testing libmudflap for Blackfin. But I think this issue affects
> all targets without TLS.
Thank you for the report.
> One libmudflap test case in the testsuite calls __wrap_calloc. In
> __wrap_calloc, __mf_state_1 is looked by __mf_get_state to see if
> it's in_malloc, reentrant or active. With emutls, HAVE_TLS is
> defined as 1 now. So __mf_state_1 has type of __thread. When emults
> tries to simulate TLS for __mf_state_1, it recursively calls
> __wrap_calloc in __emutls_get_address.
Interesting.
> To break the recursive loop, one solution is to force emutls to call
> the real calloc. [...]
If it were acceptable to change emutls on account of mudflap, this
sort of thing could work. Other alternatives would include having
emutls define something in addition to HAVE_TLS that activates the
!HAVE_TLS implementation in libmudflap/mf-hooks3.c.
- FChE