paulfloyd / freebsd_valgrind

Git repo used to Upstream the FreeBSD Port of Valgrind
GNU General Public License v2.0
15 stars 4 forks source link

helgrind/tests/tc21_pthonce is failing [clang] #78

Closed paulfloyd closed 4 years ago

paulfloyd commented 4 years ago

This is not an issue with the codegen of the guest. I've tested this with the 4 combinations of host and guest compiled with GCC and clang, and the failure is always with the host compiled with clang.

The diff does not look too serious. Instead of (gcc)

==34086== ---Thread-Announcement------------------------------------------ ==34086== ==34086== Thread #2 was created ==34086== at 0x4D144BA: thr_new (in /lib/libc.so.7) ==34086== by 0x4C6639C: pthread_create (in /lib/libthr.so.3) ==34086== by 0x4A5098A: pthread_create_WRK (hg_intercepts.c:433) ==34086== by 0x4A5199C: pthread_create (hg_intercepts.c:472) ==34086== by 0x400935: main (tc01_simple_race.c:22)

we have (clang)

==37539== ---Thread-Announcement------------------------------------------ ==37539== ==37539== Thread #3 was created ==37539== at 0x491E4BA: thr_new (in /lib/libc.so.7) ==37539== by 0x487039C: pthread_create (in /lib/libthr.so.3) ==37539== by 0x4855B44: pthread_create_WRK (hg_intercepts.c:434) ==37539== by 0x400B7A: main (tc21_pthonce.c:87)

The essential information is there, just Helgrind's redirection is missing.

With GCC and turning on the debug flag in VG_(get_StackTrace_wrk) I see

 ipsS[0]=0x04d144ba rbp 0x7fb0001c0 rsp 0x7fb0000d8
 ipsFF[1]=0x04c6639c rbp 0x7fb0001c0 rsp 0x7fb0000e0
 ipsC[2]=0x04a5098a rbp 0x7fb000400 rsp 0x7fb0001d0
 ipsC[3]=0x04a5199c rbp 0x7fb000400 rsp 0x7fb000400
 ipsC[4]=0x00400b7a rbp 0x7fb000440 rsp 0x7fb000410
 ipsC[5]=0x004007ce rbp 0x7fb000490 rsp 0x7fb000450
 ipsC[6]=0x04828fff rbp 0x00000000 rsp 0x7fb0004a0

whilst with clang that is

 ipsS[0]=0x0491e4ba rbp 0x7fb000300 rsp 0x7fb000218
 ipsFF[1]=0x0487039c rbp 0x7fb000300 rsp 0x7fb000220
 ipsC[2]=0x04855b44 rbp 0x7fb000420 rsp 0x7fb000310
 ipsC[3]=0x00400b7a rbp 0x7fb000460 rsp 0x7fb000430
 ipsC[4]=0x004007ce rbp 0x7fb0004b0 rsp 0x7fb000470
 ipsC[5]=0x04828fff rbp 0x00000000 rsp 0x7fb0004c0

So this seems to be at the level of the stack unwinding.

On Linux I get the same kind of failure.

Back on FreeBSD Running the exe standalone, there's not much difference other than the address of main (0x00000000002014c4 for clang, 0x0000000000400b7b for GCC).

Looking at the codegen for the helgrind ldpreload and pthread_create there is

Hi

I've been looking at some differences that I get when building with clang.

One kind of difference that I see is that Helgrind displays one less element in callstacks. For instance with a GCC build I might get

==34086== ---Thread-Announcement------------------------------------------ ==34086== ==34086== Thread #2 was created ==34086== at 0x4D144BA: thr_new (in /lib/libc.so.7) ==34086== by 0x4C6639C: pthread_create (in /lib/libthr.so.3) ==34086== by 0x4A5098A: pthread_create_WRK (hg_intercepts.c:433) ==34086== by 0x4A5199C: pthread_create (hg_intercepts.c:472) ==34086== by 0x400935: main (tc01_simple_race.c:22)

but the same with a clang build gives

==37539== ---Thread-Announcement------------------------------------------ ==37539== ==37539== Thread #3 was created ==37539== at 0x491E4BA: thr_new (in /lib/libc.so.7) ==37539== by 0x487039C: pthread_create (in /lib/libthr.so.3) ==37539== by 0x4855B44: pthread_create_WRK (hg_intercepts.c:434) ==37539== by 0x400B7A: main (tc21_pthonce.c:87)

(note there is no pthread_create/hg_intercepts.c line).

I think that the cause of this is the clang codegen in the helgrind preload lib.

GCC

000000000000999f <_vgw00000ZZ_libthrZdsoZa_pthreadZujoin>:
999f: 55 push %rbp
99a0: 48 89 e5 mov %rsp,%rbp
99a3: e8 a5 c1 ff ff callq 5b4d
99a8: 5d pop %rbp
99a9: c3 retq

Clang

000000000000a9f0 <_vgw00000ZZ_libthrZdsoZa_pthreadZucreate>:
a9f0: 55 push %rbp
a9f1: 48 89 e5 mov %rsp,%rbp
a9f4: 5d pop %rbp
a9f5: eb 09 jmp aa00
a9f7: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1)
a9fe: 00 00

Clang not using callq/retq seems to be the cause of the stack difference. If I force "optnone" in hg_intercepts.c then this goes away.

paulfloyd commented 4 years ago

Made a few changes to the filter and added lots of expecteds. Still 3 fails

helgrind/tests/pth_cond_destroy_busy (stderr) helgrind/tests/tc23_bogus_condwait (stderr) helgrind/tests/tls_threads (stderr)

Need to work on the filters more to reduce the number of expecteds.