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
|
3
(6) |
4
(1) |
5
(1) |
6
(2) |
|
7
(4) |
8
(7) |
9
(1) |
10
(2) |
11
(1) |
12
(4) |
13
|
|
14
(3) |
15
(2) |
16
(6) |
17
(10) |
18
(8) |
19
|
20
|
|
21
|
22
(5) |
23
(12) |
24
(5) |
25
|
26
(5) |
27
(1) |
|
28
(1) |
29
(2) |
|
|
|
|
|
|
From: Carl E. L. <ce...@us...> - 2016-02-24 23:59:58
|
I noticed that the power none/tests/ppc64/test_isa_2_07.c test is
generating some warnings from Valgrind. I have fixed a number of issues
with the test stepping off the end of the various data arrays. I have
one issue left with the BCD add and subtract instructions. I get the
message:
==28469== Use of uninitialised value of size 8
==28469== at 0x41D8BD8: _itoa_word (_itoa.c:180)
==28469== by 0x41DB05B: vfprintf@@GLIBC_2.17 (vfprintf.c:1641)
==28469== by 0x10001F83: test_av_bcd (test_isa_2_07_part1.c:1426)
==28469== by 0x1000432B: do_tests (test_isa_2_07_part1.c:2020)
==28469== by 0x1000432B: main (test_isa_2_07_part1.c:2132)
==28469==
==28469== Conditional jump or move depends on uninitialised value(s)
==28469== at 0x41DB0C8: vfprintf@@GLIBC_2.17 (vfprintf.c:1641)
==28469== by 0x41E352F: printf@@GLIBC_2.17 (printf.c:33)
==28469== by 0x10001F83: test_av_bcd (test_isa_2_07_part1.c:1426)
==28469== by 0x1000432B: do_tests (test_isa_2_07_part1.c:2020)
==28469== by 0x1000432B: main (test_isa_2_07_part1.c:2132)
==28469==
when the result of the BCD add or subtract instruction is printed.
The printing of the two source values is fine. The test case has some
similar instructions that also use V128 which are structured identically
and work fine. I can't find any issues with the test case using any
uninitialized data.
The BCD add instruction maps to Iop_BCDAdd. The instruction takes two
128 bit BCD numbers and generates a 128 bit BCD result. There is an
additional I8 field (ps) which indicates if the instruction should set
the condition code values or not. The Iop definition is as follows:
VEX/priv/ir_defs.c
case Iop_BCDAdd:
case Iop_BCDSub:
TERNARY(Ity_V128,Ity_V128, Ity_I8, Ity_V128);
In memcheck/mc_translate.c we have:
/* BCDIops */
case Iop_BCDAdd:
case Iop_BCDSub:
complainIfUndefined(mce, atom3, NULL);
return assignNew('V', mce, Ity_V128, triop(op, vatom1, vatom2, atom3));
The BCD add and subtract instructions are mapped to Iop_BCDAdd and Iop_BCDSub in
VEX/priv/guest_ppc_toIR.c:
switch (opc2) {
case 0x1: // bcdadd
DIP("bcdadd. v%d,v%d,v%d,%u\n", vRT_addr, vRA_addr, vRB_addr, ps);
assign( dst, triop( Iop_BCDAdd, mkexpr( vA ),
mkexpr( vB ), mkU8( ps ) ) );
putVReg( vRT_addr, mkexpr(dst));
return True;
case 0x41: // bcdsub
DIP("bcdsub. v%d,v%d,v%d,%u\n", vRT_addr, vRA_addr, vRB_addr, ps);
assign( dst, triop( Iop_BCDSub, mkexpr( vA ),
mkexpr( vB ), mkU8( ps ) ) );
putVReg( vRT_addr, mkexpr(dst));
return True;
The register use of the destination is set to HRmWrite, the two sources are HRmRead
the ps value use is Pri_Imm.
I have tried running the test case using gdb. I have stepped through the assembly code
where the BCD add instruction gets executed and printed the source and destination
register values as well as the shadow registers. The source shadow register values
are all zeros indicating all the bits are valid. Similarly, the shadow bits for the
result are all zeros. I have been looking for any Valgrind debug flags that might help
to debug the issue with the shadow bits. If anyone has any suggestions on debugging
the issue or sees an error in code I would appreciate the help.
Thanks.
Carl Love
|
|
From: Carl E. L. <ce...@us...> - 2016-02-24 18:37:05
|
Everyone: I have created the following bugzilla for adding the first installment of the IBM POWER ISA 3.0 support to Valgrind. https://bugs.kde.org/show_bug.cgi?id=359767 The POWER ISA 3.0 adds about 180 new instructions. This bugzilla contains the first in a series of patches to add the support for these instructions to Valgrind. The patch also contains a new test suite for the new instructions. The patch adds support for 39 of the new instructions. Each of the instructions is implemented using existing Iops. IBM pushed the assembler/compiler support for the ISA 3.0 into the GCC compiler over the last few months. I would appreciate your review comments on the patches. If you would also like to run and test the patches, let me know. You will need to download the upstream GCC compiler/assembler and build it. Then you will need to tweak the test suite so it will compile on a non ISA 3.0 system. Since all of the ISA 3.0 instructions in this patch are all emulated, you will then be able to run the test suite under Valgrind on a Power 8 machine. Thank you for your help and input with these patches. Carl Love |
|
From: <sv...@va...> - 2016-02-24 11:12:09
|
Author: mjw Date: Wed Feb 24 11:12:01 2016 New Revision: 15812 Log: Bug 359733 amd64 implement ld.so strchr/index override like x86 The suppression and redirection for ld.so strchr/index isn't needed for x86. When testing a newer glibc or calling the ld.so through an alternative path neither the suppression (doesn't match path/name) nor the redirection (triggers too late) works. Since there is already an hardwire override for strlen in amd64 ld.so anyway it makes sense to also hardware index (it is always called when ld.so loads the preload images). This was also explained in the easy hacks Fosdem session. See https://bugs.kde.org/show_bug.cgi?id=359733 for a pointer. Modified: trunk/NEWS trunk/coregrind/m_redir.c trunk/coregrind/m_trampoline.S trunk/coregrind/pub_core_trampoline.h trunk/shared/vg_replace_strmem.c Modified: trunk/NEWS ============================================================================== --- trunk/NEWS (original) +++ trunk/NEWS Wed Feb 24 11:12:01 2016 @@ -76,6 +76,7 @@ 359472 The Power PC vsubuqm instruction doesn't always give the correct result 359703 s390: wire up separate socketcalls system calls 359724 getsockname might crash - deref_UInt should call safe_to_deref +359733 amd64 implement ld.so strchr/index override like x86 n-i-bz Fix incorrect (or infinite loop) unwind on RHEL7 x86 and amd64 n-i-bz massif --pages-as-heap=yes does not report peak caused by mmap+munmap Modified: trunk/coregrind/m_redir.c ============================================================================== --- trunk/coregrind/m_redir.c (original) +++ trunk/coregrind/m_redir.c Wed Feb 24 11:12:01 2016 @@ -1353,6 +1353,9 @@ if (0==VG_(strcmp)("Memcheck", VG_(details).name)) { add_hardwired_spec( + "ld-linux-x86-64.so.2", "index", + (Addr)&VG_(amd64_linux_REDIR_FOR_index), NULL); + add_hardwired_spec( "ld-linux-x86-64.so.2", "strlen", (Addr)&VG_(amd64_linux_REDIR_FOR_strlen), # ifndef GLIBC_MANDATORY_STRLEN_REDIRECT Modified: trunk/coregrind/m_trampoline.S ============================================================================== --- trunk/coregrind/m_trampoline.S (original) +++ trunk/coregrind/m_trampoline.S Wed Feb 24 11:12:01 2016 @@ -220,6 +220,30 @@ .LfnE5: .size VG_(amd64_linux_REDIR_FOR_strlen), .-VG_(amd64_linux_REDIR_FOR_strlen) +.global VG_(amd64_linux_REDIR_FOR_index) +.type VG_(amd64_linux_REDIR_FOR_index), @function +VG_(amd64_linux_REDIR_FOR_index): + movzbl (%rdi), %eax + movl %esi, %edx + cmpb %sil, %al + jne .L4 + jmp .L5 +.L10: + addq $1, %rdi + movzbl (%rdi), %eax + cmpb %dl, %al + je .L5 +.L4: + testb %al, %al + jne .L10 + xorl %eax, %eax + ret +.L5: + movq %rdi, %rax + ret +.size VG_(amd64_linux_REDIR_FOR_index), .-VG_(amd64_linux_REDIR_FOR_index) + + /* A CIE for the above four functions, followed by their FDEs */ .section .eh_frame,"a",@progbits Modified: trunk/coregrind/pub_core_trampoline.h ============================================================================== --- trunk/coregrind/pub_core_trampoline.h (original) +++ trunk/coregrind/pub_core_trampoline.h Wed Feb 24 11:12:01 2016 @@ -71,6 +71,7 @@ extern Addr VG_(amd64_linux_REDIR_FOR_vtime); extern Addr VG_(amd64_linux_REDIR_FOR_vgetcpu); extern UInt VG_(amd64_linux_REDIR_FOR_strlen)( void* ); +extern Char* VG_(amd64_linux_REDIR_FOR_index) ( const Char*, Int ); #endif #if defined(VGP_ppc32_linux) Modified: trunk/shared/vg_replace_strmem.c ============================================================================== --- trunk/shared/vg_replace_strmem.c (original) +++ trunk/shared/vg_replace_strmem.c Wed Feb 24 11:12:01 2016 @@ -247,7 +247,7 @@ STRCHR(VG_Z_LIBC_SONAME, __strchr_sse2) STRCHR(VG_Z_LIBC_SONAME, __strchr_sse2_no_bsf) STRCHR(VG_Z_LIBC_SONAME, index) -# if !defined(VGP_x86_linux) +# if !defined(VGP_x86_linux) && !defined(VGP_amd64_linux) STRCHR(VG_Z_LD_LINUX_SO_2, strchr) STRCHR(VG_Z_LD_LINUX_SO_2, index) STRCHR(VG_Z_LD_LINUX_X86_64_SO_2, strchr) |
|
From: Anuta M. <man...@gm...> - 2016-02-24 06:30:06
|
Hi,
A few updates. I wrote a wrapper for a simple function in my client code
and that ran perfectly. However, my pthread_create wrapper still fails with
the following errors:
*--24067-- VG_USERREQ__CLIENT_CALL2: func=0x0--24067--
VG_USERREQ__CLIENT_CALL1: func=0x0Unexpected error.==24067== ==24067==
Process terminating with default action of signal 6 (SIGABRT)==24067==
at 0x5082267: raise (raise.c:55)==24067== by 0x5083EC9: abort
(abort.c:89)==24067== by 0x507B03C: __assert_fail_base
(assert.c:92)==24067== by 0x507B0F1: __assert_fail
(assert.c:101)==24067== by 0x4E376EF: pthread_create@@GLIBC_2.2.5
(allocatestack.c:591)==24067== by 0x400737: main (prog.c:18)==24067==
Aborted (core dumped)*
---------------------------------------------------------------------------------------------------------------------------------------
It is failing at prog.c:18 which is the pthread_create statement.
This is my wrapper code:
----------------------------------------------------------------------------------------------------------------------------------------
*int
I_WRAP_SONAME_FNNAME_ZZ(libpthreadZdsoZd0,pthreadZucreateZAZa)(pthread_t
*thread,const pthread_attr_t *attr,void* (*start),void *arg){ int ret;
OrigFn fn; VALGRIND_GET_ORIG_FN(fn);
CALL_FN_W_WWWW(ret,fn,thread,attr,start,arg); printf("\nPthread wrapper
just got called!\n"); return ret;}*
On Tue, Feb 23, 2016 at 2:28 PM, Anuta Mukherjee <man...@gm...> wrote:
> Hi Ivo,
>
> My tool was listed in:
> 1) configure.ac : AC_OUTPUT
> 2) Makefile.am : TOOLS
>
> I added the ones you mentioned - still the same error!
>
> I should mention : I was able to run my tool perfectly before I added
> another file with the wrapper (and changed my Makefile)
>
> On Tue, Feb 23, 2016 at 12:23 PM, Ivo Raisr <iv...@iv...> wrote:
>
>>
>>
>> 2016-02-23 5:02 GMT+00:00 Anuta Mukherjee <man...@gm...>:
>>
>>> Hi,
>>>
>>> I think I've found the problem. This is my output when I run the above
>>> commands:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *anuta@anuta-ubuntu:/valgrind/valgrind-3.11.0$ nm
>>> inst/lib/valgrind/vgpreload_helgrind-amd64-linux.so|grep -i
>>> pthreadZucreate000000000000b84f T
>>> _vgw00000ZZ_libpthreadZdsoZd0_pthreadZucreateZAZaanuta@anuta-ubuntu:/valgrind/valgrind-3.11.0$
>>> nm inst/lib/valgrind/vgpreload_tracker-amd64-linux.so|grep -i
>>> pthreadZucreatenm: 'inst/lib/valgrind/vgpreload_tracker-amd64-linux.so': No
>>> such file*
>>>
>>> My tool's preload file isn't in the inst/lib/valgrind directory at all.
>>> How do I fix this? My Makefile is exactly the same as Helgrind's, and I ran
>>> autogen, configure, make and make install as well.
>>>
>>
>> Just to make sure that you listed your tool (tracker) in:
>> 1) configure.ac, AC_CONFIG_FILES
>> 2) top-level Makefile.am, SUBDIRS
>>
>> I.
>>
>
>
>
> --
> Anuta Mukherjee,
> Dept of Computer Science Engg,
> CEG, Anna University
>
--
Anuta Mukherjee,
Dept of Computer Science Engg,
CEG, Anna University
|
Author: iraisr
Date: Wed Feb 24 03:20:17 2016
New Revision: 15811
Log:
Fix expected output of coredump generating test cases
after SVN r15810.
Now that we have AT_ENTRY in the client auxv, mdb does not
print binary name before function designation.
n-i-bz
Modified:
trunk/none/tests/amd64-solaris/coredump_single_thread.post.exp
trunk/none/tests/solaris/coredump_many_threads.post.exp
trunk/none/tests/solaris/filter_coredump_many_threads_post
trunk/none/tests/x86-solaris/coredump_single_thread.post.exp
Modified: trunk/none/tests/amd64-solaris/coredump_single_thread.post.exp
==============================================================================
--- trunk/none/tests/amd64-solaris/coredump_single_thread.post.exp (original)
+++ trunk/none/tests/amd64-solaris/coredump_single_thread.post.exp Wed Feb 24 03:20:17 2016
@@ -14,7 +14,7 @@
%r15 = 0x000000000000010e
-%rip = 0x........ coredump_single_thread`inner+0x........
+%rip = 0x........ inner+0x........
%rsp = 0x000000000000010f
@@ -22,7 +22,7 @@
%err = 0x0
---Stack trace---
-coredump_single_thread`inner
-coredump_single_thread`outer
-coredump_single_thread`main
-coredump_single_thread`_start
+inner
+outer
+main
+_start
Modified: trunk/none/tests/solaris/coredump_many_threads.post.exp
==============================================================================
--- trunk/none/tests/solaris/coredump_many_threads.post.exp (original)
+++ trunk/none/tests/solaris/coredump_many_threads.post.exp Wed Feb 24 03:20:17 2016
@@ -11,48 +11,48 @@
1 UNPARKED <NONE> 1
libc.so.1`sleep
-coredump_many_threads`main
-coredump_many_threads`_start
+main
+_start
2 UNPARKED <NONE> 1
libc.so.1`sleep
-coredump_many_threads`thread_func2
+thread_func2
libc.so.1`_thrp_setup
libc.so.1`_lwp_start
3 UNPARKED <NONE> 1
libc.so.1`sleep
-coredump_many_threads`thread_func3
+thread_func3
libc.so.1`_thrp_setup
libc.so.1`_lwp_start
4 UNPARKED <NONE> 1
libc.so.1`sleep
-coredump_many_threads`thread_func4
+thread_func4
libc.so.1`_thrp_setup
libc.so.1`_lwp_start
6 UNPARKED <NONE> 1
libc.so.1`sleep
-coredump_many_threads`thread_func6
+thread_func6
libc.so.1`_thrp_setup
libc.so.1`_lwp_start
7 UNPARKED <NONE> 1
libc.so.1`sleep
-coredump_many_threads`thread_func7
+thread_func7
libc.so.1`_thrp_setup
libc.so.1`_lwp_start
8 UNPARKED <NONE> 1
libc.so.1`sleep
-coredump_many_threads`thread_func8
+thread_func8
libc.so.1`_thrp_setup
libc.so.1`_lwp_start
9 UNPARKED <NONE> 1
libc.so.1`sleep
-coredump_many_threads`thread_func9
+thread_func9
libc.so.1`_thrp_setup
libc.so.1`_lwp_start
Modified: trunk/none/tests/solaris/filter_coredump_many_threads_post
==============================================================================
--- trunk/none/tests/solaris/filter_coredump_many_threads_post (original)
+++ trunk/none/tests/solaris/filter_coredump_many_threads_post Wed Feb 24 03:20:17 2016
@@ -15,5 +15,5 @@
perl -p -e 's/^(THREAD)\s+(STATE)\s+(SOBJ)\s+(COUNT)\s*$/$1 $2 $3 $4\n/' | \
perl -p -e 's/^(\d+)\s+(UNPARKED)\s+(\S+)\s+(\d+)/$1 $2 $3 $4/g' | \
perl -p -e 's/^\s*libc.*.so.1/libc.so.1/g' | \
-perl -p -e 's/^\s*(coredump_many_threads)/$1/g' | \
-perl -p -e 's/\+0x[0-9A-Fa-f]+//g'
+perl -p -e 's/\+0x[0-9A-Fa-f]+//g' |
+sed 's/^ *//g'
Modified: trunk/none/tests/x86-solaris/coredump_single_thread.post.exp
==============================================================================
--- trunk/none/tests/x86-solaris/coredump_single_thread.post.exp (original)
+++ trunk/none/tests/x86-solaris/coredump_single_thread.post.exp Wed Feb 24 03:20:17 2016
@@ -11,7 +11,7 @@
%fs = 0x........ %esi = 0x00000105
%gs = 0x........ %edi = 0x00000106
- %eip = 0x........ coredump_single_thread`inner+0x........
+ %eip = 0x........ inner+0x........
%kesp = 0x00000000
@@ -20,7 +20,7 @@
%err = 0x0
---Stack trace---
-coredump_single_thread`inner
-coredump_single_thread`outer
-coredump_single_thread`main
-coredump_single_thread`_start
+inner
+outer
+main
+_start
|