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
(4) |
2
(2) |
|
3
(1) |
4
(1) |
5
|
6
|
7
|
8
(1) |
9
(1) |
|
10
(4) |
11
(1) |
12
(2) |
13
(2) |
14
(3) |
15
(2) |
16
(2) |
|
17
|
18
(1) |
19
(5) |
20
|
21
|
22
(8) |
23
(4) |
|
24
(1) |
25
|
26
(3) |
27
(8) |
28
(4) |
29
(4) |
30
(1) |
|
From: Philippe W. <phi...@so...> - 2017-09-19 21:24:38
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=f1ff8597ef9c37ff1a853411b9e3be1696c36d92 commit f1ff8597ef9c37ff1a853411b9e3be1696c36d92 Author: Philippe Waroquiers <phi...@sk...> Date: Tue Sep 19 23:17:48 2017 +0200 Implement static TLS code for more platforms gdbserver_tests/hgtls is failing on a number of platforms as it looks like static tls handling is now needed. So, omplement static tls for a few more platforms. The formulas that are platform dependent are somewhat wild guesses obtained with trial and errors. Note that arm/arm64/ppc32 are not (yet) done Diff: --- coregrind/m_gdbserver/target.c | 26 +++++++++++++++++++++----- 1 file changed, 21 insertions(+), 5 deletions(-) diff --git a/coregrind/m_gdbserver/target.c b/coregrind/m_gdbserver/target.c index 10e52fc..1f03c12 100644 --- a/coregrind/m_gdbserver/target.c +++ b/coregrind/m_gdbserver/target.c @@ -712,6 +712,7 @@ Bool valgrind_get_tls_addr (ThreadState *tst, // Check we can read the modid CHECK_DEREF(lm+lm_modid_offset, sizeof(unsigned long int), "link_map modid"); modid = *(unsigned long int *)(lm+lm_modid_offset); + dlog (2, "tid %u modid %lu\n", tst->tid, modid); // Check we can access the dtv entry for modid CHECK_DEREF(dtv + 2 * modid, sizeof(CORE_ADDR), "dtv[2*modid]"); @@ -719,7 +720,6 @@ Bool valgrind_get_tls_addr (ThreadState *tst, // Compute the base address of the tls block. *tls_addr = *(dtv + 2 * modid); -#if defined(VGA_mips32) || defined(VGA_mips64) if (*tls_addr & 1) { /* This means that computed address is not valid, most probably because given module uses Static TLS. @@ -731,17 +731,24 @@ Bool valgrind_get_tls_addr (ThreadState *tst, CORE_ADDR tls_offset_addr; PtrdiffT tls_offset; - dlog(1, "computing tls_addr using static TLS\n"); + dlog(2, "tls_addr (%p & 1) => computing tls_addr using static TLS\n", + (void*) *tls_addr); /* Assumes that tls_offset is placed right before tls_modid. To check the assumption, start a gdb on none/tests/tls and do: - p &((struct link_map*)0x0)->l_tls_modid - p &((struct link_map*)0x0)->l_tls_offset */ + p &((struct link_map*)0x0)->l_tls_modid + p &((struct link_map*)0x0)->l_tls_offset + Instead of assuming this, we could calculate this similarly to + lm_modid_offset, by extending getplatformoffset to support querying + more than one offset. + */ tls_offset_addr = lm + lm_modid_offset - sizeof(PtrdiffT); // Check we can read the tls_offset. CHECK_DEREF(tls_offset_addr, sizeof(PtrdiffT), "link_map tls_offset"); tls_offset = *(PtrdiffT *)(tls_offset_addr); + dlog(2, "tls_offset_addr %p tls_offset %ld\n", + (void*)tls_offset_addr, (long)tls_offset); /* Following two values represent platform dependent constants NO_TLS_OFFSET and FORCED_DYNAMIC_TLS_OFFSET, respectively. */ @@ -751,9 +758,18 @@ Bool valgrind_get_tls_addr (ThreadState *tst, } // This calculation is also platform dependent. +#if defined(VGA_mips32) || defined(VGA_mips64) *tls_addr = ((CORE_ADDR)dtv_loc + 2 * sizeof(CORE_ADDR) + tls_offset); - } +#elif defined(VGA_ppc64be) || defined(VGA_ppc64le) + *tls_addr = ((CORE_ADDR)dtv_loc + sizeof(CORE_ADDR) + tls_offset); +#elif defined(VGA_x86) || defined(VGA_amd64) || defined(VGA_s390x) + *tls_addr = (CORE_ADDR)dtv_loc - tls_offset - sizeof(CORE_ADDR); +#else + // ppc32, arm, arm64 + dlog(0, "target.c is missing platform code for static TLS\n"); + return False; #endif + } // Finally, add tls variable offset to tls block base address. *tls_addr += offset; |
|
From: Philippe W. <phi...@so...> - 2017-09-19 21:15:33
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=92ec6d08bbe3e06e76b13373ff31ff81d94550b7 commit 92ec6d08bbe3e06e76b13373ff31ff81d94550b7 Author: Philippe Waroquiers <phi...@sk...> Date: Tue Sep 19 23:12:35 2017 +0200 Fix assert on ppc32 due to typo for GPR28 The below commit introduced a regression on ppc32 ommit 00d4667295a821fef9eb198abcb0c942dffb6045 Author: Ivo Raisr <iv...@iv...> Date: Wed Sep 6 08:10:36 2017 +0200 Reorder allocatable registers for AMD64, X86, and PPC so that the callee saved are listed first. Helper calls always trash all caller saved registers. By listing the callee saved first then VEX register allocator (both v2 and v3) is more likely to pick them and does not need to spill that much before helper calls. Investigation/fix done by Ivo. Diff: --- VEX/priv/host_ppc_defs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/VEX/priv/host_ppc_defs.h b/VEX/priv/host_ppc_defs.h index 8ee789a..27b3b38 100644 --- a/VEX/priv/host_ppc_defs.h +++ b/VEX/priv/host_ppc_defs.h @@ -71,7 +71,7 @@ ST_IN HReg hregPPC_GPR24 ( Bool mode64 ) { return GPR(mode64, 24, 10, 10); } ST_IN HReg hregPPC_GPR25 ( Bool mode64 ) { return GPR(mode64, 25, 11, 11); } ST_IN HReg hregPPC_GPR26 ( Bool mode64 ) { return GPR(mode64, 26, 12, 12); } ST_IN HReg hregPPC_GPR27 ( Bool mode64 ) { return GPR(mode64, 27, 13, 13); } -ST_IN HReg hregPPC_GPR28 ( Bool mode64 ) { return GPR(mode64, 28, 14, 44); } +ST_IN HReg hregPPC_GPR28 ( Bool mode64 ) { return GPR(mode64, 28, 14, 14); } ST_IN HReg hregPPC_GPR3 ( Bool mode64 ) { return GPR(mode64, 3, 15, 15); } ST_IN HReg hregPPC_GPR4 ( Bool mode64 ) { return GPR(mode64, 4, 16, 16); } |
|
From: Philippe W. <phi...@sk...> - 2017-09-19 20:52:04
|
It looks like all ppc32 is broken on gcc110.
I do not know exactly when it was broken, but it was sometime between
valgrind-3.14.0.SVN-16452M-vex-3398 and the current git version
valgrind-3.14.0.GIT-b9df4c8dec-20170916
any ppc32 under valgrind directly asserts with the below assert.
It might be linked with the work on the v2 and/or v3 regalloc
Philippe
./vg-in-place -q ./none/tests/ppc32/test_fx
vex: priv/host_generic_regs.c:114 (RRegUniverse__check_is_sane): Assertion `hregIndex(reg) == i' failed.
vex storage: T total 0 bytes allocated
vex storage: P total 0 bytes allocated
valgrind: the 'impossible' happened:
LibVEX called failure_exit().
host stacktrace:
==44115== at 0x58076B74: show_sched_status_wrk (m_libcassert.c:355)
==44115== by 0x58076CC7: report_and_quit (m_libcassert.c:426)
==44115== by 0x58076F3F: panic (m_libcassert.c:502)
==44115== by 0x58076F3F: vgPlain_core_panic_at (m_libcassert.c:507)
==44115== by 0x58076F73: vgPlain_core_panic (m_libcassert.c:512)
==44115== by 0x58098BDB: failure_exit (m_translate.c:740)
==44115== by 0x5816EBEF: vex_assert_fail (main_util.c:247)
==44115== by 0x581D521B: RRegUniverse__check_is_sane (host_generic_regs.c:114)
==44115== by 0x581B53DF: getRRegUniverse_PPC (host_ppc_defs.c:152)
==44115== by 0x5816DA3B: libvex_BackEnd (main_main.c:895)
==44115== by 0x5816DA3B: LibVEX_Translate (main_main.c:1198)
==44115== by 0x5809B2C7: vgPlain_translate (m_translate.c:1794)
==44115== by 0x580DD7E7: handle_tt_miss (scheduler.c:1056)
==44115== by 0x580DD7E7: vgPlain_scheduler (scheduler.c:1417)
==44115== by 0x580F2A7F: thread_wrapper (syswrap-linux.c:103)
==44115== by 0x580F2A7F: run_a_thread_NORETURN (syswrap-linux.c:156)
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable (lwpid 44115)
==44115== at 0x401B204: _start (in /usr/lib/ld-2.17.so)
|
|
From: Mark W. <ma...@kl...> - 2017-09-19 09:19:31
|
Hi, On Tue, 2017-09-19 at 06:43 +0200, Ivo Raisr wrote: > Dear Valgrind and gdb hackers, > > Please have a look at FOSDEM 2018 devroom proposal. > Let me know your comments, suggestions, etc. > The deadline is tomorrow (20th September). > > ------------------------------------------------------- > Title: Valgrind, gdb, debugging tools > Coordinator: Ivo Raisr > Coordinator email: iv...@iv... > Secondary contact: Mark Wielaard (if Mark has no strict objections) > Secondary email: ma...@kl... I certainly have no objections :) But it would be good to also have one of the gdb hackers as contact. If only to better judge the talk proposals. Any volunteers? > Description: > The valgrind and gdb hackers would like to meet during FOSDEM 2018. > > Several core developers said they would like to attend a hacker > meeting to meet each other in person and to coordinate various > topics. And we would like to invite other hackers of toolchain > projects to discuss cross project ideas. I would also mention we had a successful combined devroom in 2014: https://archive.fosdem.org/2014/schedule/track/valgrind/ > Subjects for core hackers, new developers, users, packagers and cross > project functionality, that we would like to discuss and give > presentations on include: > > - The recently added functional changes (for valgrind and gdb users). > - Get feedback on what what kinds of new functionality would > be useful. Which tools and functionality users would like to see. > (valgrind and gdb users). > - How to add simple Valgrind features (adding syscalls for a platform > or VEX > instructions for a architecture port). (new Valgrind core > developers). > - Infrastructure changes to the JIT framework. (core hackers). > - Discuss release/bugfixing strategy/policy (core hackers, > packagers). > - Packaging Valgrind and gdb for distros, handling patches, > suppressions, etc. > (packagers). If we are talking combining the power of debugging tools I think there should be some suggestions for talks about: - Advances in gdbserver and the GDB remote serial protocol. Connecting debugging tools together. - Latest DWARF extensions, going from binary back to source. - Multi, multi, multi... threads, processes and targets. Debugging anything, everywhere. Dealing with complex systems. - Dealing with the dynamic loader and the kernel. Intercepting and interposing functions and events. > Coordinator's affinity to the topic of the devroom: > core hacker, Solaris port maintainer > > Why does it fit FOSDEM > Valgrind is an instrumentation framework for building dynamic > analysis > tools. There are Valgrind tools that can automatically detect many > memory management and threading bugs, and profile your programs in > detail. You can also use Valgrind to build new tools. > > GDB, the GNU Project debugger, allows you to see what is going on > `inside' another program while it executes -- or what another program > was doing at the moment it crashed. > > Valgrind and GDB is Open Source / Free Software, and is freely > available under the GNU General Public License, version 2. are ... version 2 and 3 (or later). > Relevant URLs: > Valgrind website: http://www.valgrind.org > GDB website: https://www.gnu.org/software/gdb/ > > Timeslot: > Half day If we make it a shared debugging tools devroom and both gdb and valgrind hackers submit talks then I would request a whole day. Cheers, Mark |
|
From: Ivo R. <iv...@iv...> - 2017-09-19 04:43:14
|
Dear Valgrind and gdb hackers, Please have a look at FOSDEM 2018 devroom proposal. Let me know your comments, suggestions, etc. The deadline is tomorrow (20th September). I. ------------------------------------------------------- Title: Valgrind, gdb, debugging tools Coordinator: Ivo Raisr Coordinator email: iv...@iv... Secondary contact: Mark Wielaard (if Mark has no strict objections) Secondary email: ma...@kl... Description: The valgrind and gdb hackers would like to meet during FOSDEM 2018. Several core developers said they would like to attend a hacker meeting to meet each other in person and to coordinate various topics. And we would like to invite other hackers of toolchain projects to discuss cross project ideas. Subjects for core hackers, new developers, users, packagers and cross project functionality, that we would like to discuss and give presentations on include: - The recently added functional changes (for valgrind and gdb users). - Get feedback on what what kinds of new functionality would be useful. Which tools and functionality users would like to see. (valgrind and gdb users). - How to add simple Valgrind features (adding syscalls for a platform or VEX instructions for a architecture port). (new Valgrind core developers). - Infrastructure changes to the JIT framework. (core hackers). - Discuss release/bugfixing strategy/policy (core hackers, packagers). - Packaging Valgrind and gdb for distros, handling patches, suppressions, etc. (packagers). Coordinator's affinity to the topic of the devroom: core hacker, Solaris port maintainer Why does it fit FOSDEM Valgrind is an instrumentation framework for building dynamic analysis tools. There are Valgrind tools that can automatically detect many memory management and threading bugs, and profile your programs in detail. You can also use Valgrind to build new tools. GDB, the GNU Project debugger, allows you to see what is going on `inside' another program while it executes -- or what another program was doing at the moment it crashed. Valgrind and GDB is Open Source / Free Software, and is freely available under the GNU General Public License, version 2. Relevant URLs: Valgrind website: http://www.valgrind.org GDB website: https://www.gnu.org/software/gdb/ Timeslot: Half day Special requirements: |