diff mbox

[PING] : [PATCH]: Conditionally include target specific files while building TSAN

Message ID 20150122204447.GN1746@tucnak.redhat.com
State New
Headers show

Commit Message

Jakub Jelinek Jan. 22, 2015, 8:44 p.m. UTC
On Thu, Jan 22, 2015 at 06:16:53PM +0400, Dmitry Vyukov wrote:
> On Thu, Jan 22, 2015 at 5:03 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> > On Thu, Jan 22, 2015 at 07:30:50PM +0530, Venkataramanan Kumar wrote:
> >> ping.
> >>
> >> Forgot to mention, GCC bootstraps and regression testing passed on x86_64.
> >
> > Well, without a change from upstream to guard the HACKY_CALL and actual tsan
> > port to non-x86_64 this patch doesn't solve anything.
> 
> 
> I've just committed that change upstream:
> http://llvm.org/viewvc/llvm-project?view=revision&revision=226829
> Now we need to summon +Kostya to update gcc version of runtime.

Here is what I've committed:

2015-01-22  Jakub Jelinek  <jakub@redhat.com>

	* tsan/tsan_rtl.h: Cherry pick upstream r226829.



	Jakub

Comments

Venkataramanan Kumar Jan. 23, 2015, 11:56 a.m. UTC | #1
Hi Jakub,

I committed the patch with the change log corrections you said.

https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=220034

regards,
Venkat.

On 23 January 2015 at 02:14, Jakub Jelinek <jakub@redhat.com> wrote:
> On Thu, Jan 22, 2015 at 06:16:53PM +0400, Dmitry Vyukov wrote:
>> On Thu, Jan 22, 2015 at 5:03 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>> > On Thu, Jan 22, 2015 at 07:30:50PM +0530, Venkataramanan Kumar wrote:
>> >> ping.
>> >>
>> >> Forgot to mention, GCC bootstraps and regression testing passed on x86_64.
>> >
>> > Well, without a change from upstream to guard the HACKY_CALL and actual tsan
>> > port to non-x86_64 this patch doesn't solve anything.
>>
>>
>> I've just committed that change upstream:
>> http://llvm.org/viewvc/llvm-project?view=revision&revision=226829
>> Now we need to summon +Kostya to update gcc version of runtime.
>
> Here is what I've committed:
>
> 2015-01-22  Jakub Jelinek  <jakub@redhat.com>
>
>         * tsan/tsan_rtl.h: Cherry pick upstream r226829.
>
> --- libsanitizer/tsan/tsan_rtl.h        (revision 226828)
> +++ libsanitizer/tsan/tsan_rtl.h        (revision 226829)
> @@ -679,7 +679,7 @@ void AcquireReleaseImpl(ThreadState *thr
>  // The trick is that the call preserves all registers and the compiler
>  // does not treat it as a call.
>  // If it does not work for you, use normal call.
> -#if TSAN_DEBUG == 0
> +#if TSAN_DEBUG == 0 && defined(__x86_64__)
>  // The caller may not create the stack frame for itself at all,
>  // so we create a reserve stack frame for it (1024b must be enough).
>  #define HACKY_CALL(f) \
>
>
>         Jakub
Rainer Orth Jan. 23, 2015, 8:53 p.m. UTC | #2
Hi Venkat,

> I committed the patch with the change log corrections you said.
>
> https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=220034

unfortunately, it broke bootstrap for an i686-unknown-linux-gnu
--enable-targets=all build: the 64-bit libtsan.so fails to link:

.libs/tsan_interface_atomic.o: In function `__tsan::TraceAddEvent(__tsan::ThreadState*, __tsan::FastState, __tsan::EventType, unsigned long long)':
/vol/gcc/src/hg/trunk/local/libsanitizer/tsan/tsan_rtl.h:715: undefined reference to `__tsan_trace_switch_thunk'
[...
.libs/tsan_rtl_mutex.o:/vol/gcc/src/hg/trunk/local/libsanitizer/tsan/tsan_rtl.h:715: more undefined references to `__tsan_trace_switch_thunk' follow
/vol/gcc/bin/i686/gld-2.24: .libs/libtsan.so.0.0.0: hidden symbol `__tsan_report_race_thunk' isn't defined
/vol/gcc/bin/i686/gld-2.24: final link failed: Bad valu
collect2: error: ld returned 1 exit status
make[6]: *** [libtsan.la] Error 1

The problem is that libsanitizer/configure.ac checks for target
x86_64-*-linux-*, which is wrong in this case.  I believe that you need
something like libgcc's host_address instead and then check for either
x86_64-*-linux-* or i?86-*-linux-* and host_address=64.

	Rainer
Venkataramanan Kumar Jan. 24, 2015, 2:55 a.m. UTC | #3
Hi Rainer,

Yes thanks I will work on fixing this. Let me know if I need to revert
the patch meanwhile.

regards,
Venkat.

On 24 January 2015 at 02:23, Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote:
> Hi Venkat,
>
>> I committed the patch with the change log corrections you said.
>>
>> https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=220034
>
> unfortunately, it broke bootstrap for an i686-unknown-linux-gnu
> --enable-targets=all build: the 64-bit libtsan.so fails to link:
>
> .libs/tsan_interface_atomic.o: In function `__tsan::TraceAddEvent(__tsan::ThreadState*, __tsan::FastState, __tsan::EventType, unsigned long long)':
> /vol/gcc/src/hg/trunk/local/libsanitizer/tsan/tsan_rtl.h:715: undefined reference to `__tsan_trace_switch_thunk'
> [...
> .libs/tsan_rtl_mutex.o:/vol/gcc/src/hg/trunk/local/libsanitizer/tsan/tsan_rtl.h:715: more undefined references to `__tsan_trace_switch_thunk' follow
> /vol/gcc/bin/i686/gld-2.24: .libs/libtsan.so.0.0.0: hidden symbol `__tsan_report_race_thunk' isn't defined
> /vol/gcc/bin/i686/gld-2.24: final link failed: Bad valu
> collect2: error: ld returned 1 exit status
> make[6]: *** [libtsan.la] Error 1
>
> The problem is that libsanitizer/configure.ac checks for target
> x86_64-*-linux-*, which is wrong in this case.  I believe that you need
> something like libgcc's host_address instead and then check for either
> x86_64-*-linux-* or i?86-*-linux-* and host_address=64.
>
>         Rainer
>
> --
> -----------------------------------------------------------------------------
> Rainer Orth, Center for Biotechnology, Bielefeld University
Rainer Orth Jan. 24, 2015, 7:23 a.m. UTC | #4
Hi Venkat,

> Yes thanks I will work on fixing this. Let me know if I need to revert
> the patch meanwhile.

I don't think this is urgent enough to justify reversion.

Thanks.
        Rainer
diff mbox

Patch

--- libsanitizer/tsan/tsan_rtl.h	(revision 226828)
+++ libsanitizer/tsan/tsan_rtl.h	(revision 226829)
@@ -679,7 +679,7 @@  void AcquireReleaseImpl(ThreadState *thr
 // The trick is that the call preserves all registers and the compiler
 // does not treat it as a call.
 // If it does not work for you, use normal call.
-#if TSAN_DEBUG == 0
+#if TSAN_DEBUG == 0 && defined(__x86_64__)
 // The caller may not create the stack frame for itself at all,
 // so we create a reserve stack frame for it (1024b must be enough).
 #define HACKY_CALL(f) \