You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(2) |
2
(9) |
|
3
(1) |
4
|
5
(1) |
6
(3) |
7
(1) |
8
|
9
(3) |
|
10
|
11
(4) |
12
|
13
(24) |
14
(14) |
15
(22) |
16
|
|
17
|
18
(4) |
19
(4) |
20
(3) |
21
|
22
|
23
|
|
24
|
25
(2) |
26
|
27
(2) |
28
|
29
|
30
|
|
31
|
|
|
|
|
|
|
|
From: Paul F. <pj...@wa...> - 2020-05-09 19:01:18
|
> On 9 May 2020, at 13:59, Eliot Moss <mo...@cs...> wrote: > >> > > I believe what you are seeing is called "tail call elimination" - if a function ends with a > call, that call can be optimized to a jump, at least under some circumstances. This is > perfectly legitimate. > Hi I know what the optimisation is. I’m not familiar with the heuristics used to try to build the callstack and the dwarf2/3 CFI stack unwinding. So I just wanted to make sure that this difference is to be expected. A+ Paul |
|
From: Eliot M. <mo...@cs...> - 2020-05-09 12:17:16
|
On 5/9/2020 2:42 AM, Paul FLOYD wrote: > 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. > > Here is the GCC codegen, a classic function call > > > 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 optimizes the call and uses a jump > > 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 > > Am I right in assuming it is this 'jmp' rather than 'callq / retq' that is causing "VG_(get_StackTrace_wrk)" to see one less element in the callstack? > > The difference goes away if I force 'pthread_create' to be not optimized. > > #define PTH_FUNC(ret_ty, f, args...) \ > ret_ty I_WRAP_SONAME_FNNAME_ZZ(VG_Z_LIBPTHREAD_SONAME,f)(args); \ > __attribute__((optnone)) \ > ret_ty I_WRAP_SONAME_FNNAME_ZZ(VG_Z_LIBPTHREAD_SONAME,f)(args) > > (Not that I'm seriously suggesting that). I believe what you are seeing is called "tail call elimination" - if a function ends with a call, that call can be optimized to a jump, at least under some circumstances. This is perfectly legitimate. Regards - Eliot Moss |
|
From: Paul F. <pj...@wa...> - 2020-05-09 06:43:06
|
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. Here is the GCC codegen, a classic function call 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 optimizes the call and uses a jump 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 Am I right in assuming it is this 'jmp' rather than 'callq / retq' that is causing "VG_(get_StackTrace_wrk)" to see one less element in the callstack? The difference goes away if I force 'pthread_create' to be not optimized. #define PTH_FUNC(ret_ty, f, args...) \ ret_ty I_WRAP_SONAME_FNNAME_ZZ(VG_Z_LIBPTHREAD_SONAME,f)(args); \ __attribute__((optnone)) \ ret_ty I_WRAP_SONAME_FNNAME_ZZ(VG_Z_LIBPTHREAD_SONAME,f)(args) (Not that I'm seriously suggesting that). A+ Paul |