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
(17) |
2
(21) |
3
(17) |
4
(28) |
5
(21) |
6
(11) |
|
7
(13) |
8
(21) |
9
(21) |
10
(9) |
11
(11) |
12
(15) |
13
(23) |
|
14
(15) |
15
(22) |
16
(28) |
17
(12) |
18
(15) |
19
(8) |
20
(7) |
|
21
(8) |
22
(12) |
23
(13) |
24
(7) |
25
(7) |
26
(3) |
27
(9) |
|
28
(13) |
29
(7) |
30
(7) |
31
(9) |
|
|
|
|
From: Chris J. <ch...@at...> - 2004-03-09 22:52:44
|
> Where function_entry/exit_hook are simply increment or decrement counters. > > I expect that this will give me the number of instrumented > functions inside the > stack, but sometimes I get more exits than entrances. > > Can anyone explain why this happens? Just a guess, but the Valgrind simulated CPU starts off with a non-empty call stack - maybe that can account for the mismatch. For example: __strtold_internal + 6480: RETURN dis_Grp2 + 180 dis_Grp2 + 180: CALL vfscanf + 6096 vfscanf + 6145: RETURN dis_Grp2 + 185 dis_Grp2 + 186: RETURN _dl_init + 707 ... _dl_init + 230: RETURN _dl_start_user + 54 Chris |
|
From: Nicholas N. <nj...@ca...> - 2004-03-09 13:37:42
|
CVS commit by nethercote:
Added Cyberquery, Cyberscreen.
M +6 -0 users.html 1.57
--- devel-home/valgrind/users.html #1.56:1.57
@@ -90,4 +90,7 @@
<dd>A search and navigation platform, including search engine, XML
processing libraries, and statistical linguistics.
+
+<dt><a href="http://www.cyberscience.com/cyberquery.html">Cyberquery</a>
+<dd>A high performance ad-hoc query and production reporting system.
</dl>
@@ -196,4 +199,7 @@
<dt><a href="http://www.st.com/">ST200 VLIW C compiler</a>
<dd>The STMicroelectronics ST200 VLIW production C compiler.
+
+<dt><a href="http://www.cyberscience.com/cyberscreen.html">Cyberscreen</a>
+<dd>A fourth generation language and rapid application development environment.
</dl>
|
|
From: Tom H. <th...@cy...> - 2004-03-09 12:20:42
|
In message <164...@ca...>
Paul Mackerras <pa...@sa...> wrote:
> By the way, how do you cope with self-modifying code in valgrind on
> x86? Procedure linkage through a PLT presumably involves ld.so
> modifying the PLT entry, doesn't it?
No it doesn't actually. This is what the PLT entry for printf looks
like the first time it is called:
(gdb) disas 0x0804828c
Dump of assembler code for function printf:
0x0804828c <printf+0>: jmp *0x804954c
0x08048292 <printf+6>: push $0x8
0x08048297 <printf+11>: jmp 0x804826c <_init+24>
End of assembler dump.
(gdb) p/x *(unsigned long *)0x804954c
$2 = 0x8048292
and then the second time:
(gdb) disas 0x0804828c
Dump of assembler code for function printf:
0x0804828c <printf+0>: jmp *0x804954c
0x08048292 <printf+6>: push $0x8
0x08048297 <printf+11>: jmp 0x804826c <_init+24>
End of assembler dump.
(gdb) p/x *(unsigned long *)0x804954c
$3 = 0x4204f4a0
As you can see, the first instruction is an indirect jump which
initially points to the next instruction which pushes the entry
number and calls the dynamic resolver.
The second time round, the indirection table has been updated so
that initial indirect jump now calls directly to the function.
So there is no code change occurring, just an update to the
indirection table which is data.
The main self-modifying code problem we have on x86 is the trampolines
which gcc puts on the stack when nested functions are used, and we
don't have a good solution for that at the moment as on x86 the caches
are always coherent I believe so there is no instruction to hint to us
that the translation needs to be discarded.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Paul M. <pa...@sa...> - 2004-03-09 12:05:13
|
By the way, how do you cope with self-modifying code in valgrind on x86? Procedure linkage through a PLT presumably involves ld.so modifying the PLT entry, doesn't it? Paul. |
|
From: Paul M. <pa...@sa...> - 2004-03-09 12:01:50
|
Well, I found out why valgrind was running sooo sloooowly on PPC. It was spending all of its time (well, 430 out of 520 seconds on one test) in VG_(invalidate_translations). Some background: the PPC architecture doesn't require the i-cache to snoop anything, and in all current implementations it doesn't. Instead, software has to use the cache management instructions when it changes some instructions in memory and then wants to execute them. Notably there is the dcbst (data cache block store) instruction, which makes sure that a given cache line is written back to memory if it is modified, and the icbi (instruction cache block invalidate) instruction, which invalidates a cache line if it is present in the icache. These instructions can be used in userland, and are used by glibc for example when changing a PLT entry to branch directly to the desired procedure. In valgrind, I made the icbi instruction emulation call VG_(invalidate_translations) to get rid of any translation of any instructions in that cache line. But that routine scans the whole of vg_tt and the whole of every sector in the TC, and it is stunningly slow (and it also completely trashes the L2 cache for good measure :). I made two changes: I arranged for all the blocks that chain to a given BB to be linked together in a linked list, and I modified the icbi emulation to scan only the part of the TT which could correspond to the cache line being invalidated. The first change means that when deleting a block, I can unchain all the BBs that were chained to it without scanning the whole TC. (This also helps when discarding a sector of TC.) The second change means that we don't scan the whole 2.4MB of the TT, only about 256 bytes of it (plus a bit more, depending on how full the TT is; I keep scanning until I find an empty entry). With this change, the time to start up mozilla and quit is reduced from 520 seconds to 60 seconds. Openoffice also starts up much much more quickly. The latest tarball and patch are in http://ozlabs.org/~paulus/ as usual. Paul. |
|
From: Tom H. <th...@cy...> - 2004-03-09 10:08:33
|
CVS commit by thughes: Anonymise path names for libc's built with debg symbols. M +3 -0 corecheck/tests/filter_fdleak 1.3 M +4 -1 memcheck/tests/filter_stderr 1.11 --- valgrind/corecheck/tests/filter_fdleak #1.2:1.3 @@ -16,4 +16,7 @@ sed "s/(in \/.*libc.*)$/(in \/...libc...)/" | +# Anonymise paths like "xxx (../sysdeps/unix/sysv/linux/quux.c:129)" +sed "s/(\.\.\/sysdeps\/unix\/sysv\/linux\/.*\.c:[0-9]*)$/(in \/...libc...)/" | + # Anonymise paths like "__libc_start_main (../foo/bar/libc-quux.c:129)" sed "s/__libc_\(.*\) (.*)$/__libc_\1 (...libc...)/" | --- valgrind/memcheck/tests/filter_stderr #1.10:1.11 @@ -17,5 +17,8 @@ # Anonymise paths like "(within /foo/bar/libc-baz.so)" -sed "s/(within \/.*libc.*)$/(within \/...libc...)/" | +sed "s/(within \/.*libc.*)$/(within \/...libc...)/" | + +# Anonymise paths like "xxx (../sysdeps/unix/sysv/linux/quux.c:129)" +sed "s/(\.\.\/sysdeps\/unix\/sysv\/linux\/.*\.c:[0-9]*)$/(in \/...libc...)/" | # Anonymise paths like "__libc_start_main (../foo/bar/libc-quux.c:129)" |
|
From: Nicholas N. <nj...@ca...> - 2004-03-09 09:45:24
|
CVS commit by nethercote: Added AbiWord M +7 -4 users.html 1.56 --- devel-home/valgrind/users.html #1.55:1.56 @@ -7,7 +7,7 @@ The following projects use or have used Valgrind. <p> -The short list: OpenOffice, StarOffice, Mozilla, Opera, KDE, GNOME, Evolution, -MySQL, PostgreSQL, Perl, PHP, Mono, Samba, Nasa Mars Lander software, SAS, The -GIMP, Ogg Vorbis, Unreal Tournament, Medal of Honour... +The short list: OpenOffice, StarOffice, AbiWord, Mozilla, Opera, KDE, GNOME, +Evolution, MySQL, PostgreSQL, Perl, PHP, Mono, Samba, Nasa Mars Lander +software, SAS, The GIMP, Ogg Vorbis, Unreal Tournament, Medal of Honour... <p> The long list... @@ -23,4 +23,7 @@ <dd>A commercial multi-platform office productivity suite, based on OpenOffice. +<dt><a href="http://www.abisource.com/">AbiWord</a> +<dd>A multi-platform, full-featured and ultra-efficient word processor. + <dt><a href="http://www.koffice.org/">KOffice</a> <dd>A multi-application, integrated office suite. @@ -375,5 +378,5 @@ multiple connections. -<dt><a href="http://psi.affinix.com">Psi</a> +<dt><a href="http://psi.affinix.com/">Psi</a> <dd>A cross-platform Jabber client designed for the Jabber power user. |
|
From: Nicholas N. <nj...@ca...> - 2004-03-09 09:39:41
|
CVS commit by nethercote: whoops M +1 -2 users.html 1.55 --- devel-home/valgrind/users.html #1.54:1.55 @@ -376,6 +376,5 @@ <dt><a href="http://psi.affinix.com">Psi</a> -<dd>Description: A cross-platform Jabber client designed for the Jabber power - user. +<dd>A cross-platform Jabber client designed for the Jabber power user. <dt><a href="http://www.pldaniels.com/ripmime/">ripMIME</a> |
|
From: Nicholas N. <nj...@ca...> - 2004-03-09 09:38:53
|
CVS commit by nethercote:
Added Psi
M +4 -0 users.html 1.54
--- devel-home/valgrind/users.html #1.53:1.54
@@ -375,4 +375,8 @@
multiple connections.
+<dt><a href="http://psi.affinix.com">Psi</a>
+<dd>Description: A cross-platform Jabber client designed for the Jabber power
+ user.
+
<dt><a href="http://www.pldaniels.com/ripmime/">ripMIME</a>
<dd>An email decoding engine and library.
|
|
From: Nicholas N. <nj...@ca...> - 2004-03-09 09:26:52
|
On Fri, 5 Mar 2004 sun...@te... wrote: > I expect that this will give me the number of instrumented functions > inside the stack, but sometimes I get more exits than entrances. > > Can anyone explain why this happens? What does is_entry do? Detecting function entry/exit is harder than you might expect, when you only have the dynamic instruction stream to go by. BTW, my mailer has choked on a couple of your messages, due to: Formatting error: Non-hexadecimal character in QP encoding I had to read the raw mail folder to see your message. I don't know if others are having the same problem. N |
|
From: Tom H. <th...@cy...> - 2004-03-09 09:25:40
|
CVS commit by thughes: Add an alternate (appropriately filtered) result for some systems. A writev.stderr.exp2 1.1 M +3 -0 filter_stderr 1.10 --- valgrind/memcheck/tests/filter_stderr #1.9:1.10 @@ -16,4 +16,7 @@ sed "s/(in \/.*libc.*)$/(in \/...libc...)/" | +# Anonymise paths like "(within /foo/bar/libc-baz.so)" +sed "s/(within \/.*libc.*)$/(within \/...libc...)/" | + # Anonymise paths like "__libc_start_main (../foo/bar/libc-quux.c:129)" sed "s/__libc_\(.*\) (.*)$/__libc_\1 (...libc...)/" |
|
From: Tom H. <th...@cy...> - 2004-03-09 08:59:06
|
CVS commit by thughes: Fix expected standard error output for mmxext tests to resolve differences in the amount of whitespace left with different skins. M +0 -2 addrcheck/tests/insn_mmxext.stderr.exp 1.2 M +0 -2 cachegrind/tests/insn_mmxext.stderr.exp 1.2 M +0 -2 helgrind/tests/insn_mmxext.stderr.exp 1.2 M +0 -2 memcheck/tests/insn_mmxext.stderr.exp 1.2 --- valgrind/addrcheck/tests/insn_mmxext.stderr.exp #1.1:1.2 @@ -1,2 +0,0 @@ - - --- valgrind/cachegrind/tests/insn_mmxext.stderr.exp #1.1:1.2 @@ -1,2 +0,0 @@ - - --- valgrind/helgrind/tests/insn_mmxext.stderr.exp #1.1:1.2 @@ -1,2 +0,0 @@ - - --- valgrind/memcheck/tests/insn_mmxext.stderr.exp #1.1:1.2 @@ -1,2 +0,0 @@ - - |
|
From: Tom H. <to...@co...> - 2004-03-09 08:55:55
|
In message <1078820531.26569.0.camel@localhost.localdomain>
Jeremy Fitzhardinge <je...@go...> wrote:
> On Mon, 2004-03-08 at 23:21, Tom Hughes wrote:
>
>> helgrind/tests/insn_mmxext (stderr)
>> memcheck/tests/insn_mmxext (stderr)
>
> I notice these are failing on a lot of your tests. I presume you've got
> an AMD CPU? How are these failing?
All the machines running the tests are Athlon XP or MP of one speed
or another, but the failures appear to be down to a whitespace change.
Those test suites all seem to strip the blank lines, but unlike the
other tests you didn't update the expected output for mmxext, so I'm
about to do it.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Jeremy F. <je...@go...> - 2004-03-09 08:30:51
|
On Mon, 2004-03-08 at 23:21, Tom Hughes wrote: > helgrind/tests/insn_mmxext (stderr) > memcheck/tests/insn_mmxext (stderr) I notice these are failing on a lot of your tests. I presume you've got an AMD CPU? How are these failing? J |
|
From: Tom H. <th...@cy...> - 2004-03-09 07:47:42
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-03-09 07:19:34 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow shorts: valgrind ./shorts smc1: valgrind ./smc1 syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 148 tests, 9 stderr failures, 0 stdout failures ================= addrcheck/tests/insn_mmxext (stderr) cachegrind/tests/insn_mmxext (stderr) corecheck/tests/fdleak_fcntl (stderr) helgrind/tests/inherit (stderr) helgrind/tests/insn_mmxext (stderr) memcheck/tests/badfree-2trace (stderr) memcheck/tests/execve (stderr) memcheck/tests/insn_mmxext (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-03-09 07:37:05
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-03-09 07:24:08 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow smc1: valgrind ./smc1 syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 148 tests, 10 stderr failures, 0 stdout failures ================= addrcheck/tests/insn_mmxext (stderr) cachegrind/tests/insn_mmxext (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/insn_mmxext (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/insn_mmxext (stderr) memcheck/tests/nanoleak (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-03-09 07:33:54
|
Nightly build on audi ( Red Hat 9 ) started at 2004-03-09 07:21:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow resolv: valgrind ./resolv seg_override: valgrind ./seg_override sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 148 tests, 5 stderr failures, 0 stdout failures ================= addrcheck/tests/insn_mmxext (stderr) cachegrind/tests/insn_mmxext (stderr) helgrind/tests/inherit (stderr) helgrind/tests/insn_mmxext (stderr) memcheck/tests/insn_mmxext (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-03-09 07:30:27
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-03-09 07:17:21 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 148 tests, 13 stderr failures, 1 stdout failure ================= addrcheck/tests/insn_mmxext (stderr) cachegrind/tests/insn_mmxext (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/insn_mmxext (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/badfree-2trace (stderr) memcheck/tests/badjump (stderr) memcheck/tests/brk (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/insn_mmxext (stderr) memcheck/tests/new_nothrow (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2004-03-09 07:30:24
|
Nightly build on dunsmere ( Fedora Core 1 ) started at 2004-03-09 07:17:54 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_dup2 (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_open (stderr) corecheck/tests/fdleak_pipe (stderr) corecheck/tests/fdleak_socketpair (stderr) helgrind/tests/inherit (stderr) helgrind/tests/insn_mmxext (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/fwrite (stderr) memcheck/tests/insn_mmxext (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/writev (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Jeremy F. <je...@go...> - 2004-03-09 01:06:37
|
CVS commit by fitzhardinge:
Raise RLIMIT_AS to max allowable, so that we can create the large mappings
we need to. If the hard limit is set to low, then things will fail as
large mmaps fail.
M +8 -0 stage1.c 1.8
--- valgrind/coregrind/stage1.c #1.7:1.8
@@ -39,4 +39,5 @@
#include <fcntl.h>
#include <errno.h>
+#include <sys/resource.h>
#include "vg_include.h"
@@ -197,4 +198,5 @@ static void hoops(void)
int main(int argc, char **argv)
{
+ struct rlimit rlim;
const char *cp = getenv(VALGRINDLIB);
@@ -206,4 +208,10 @@ int main(int argc, char **argv)
our_argc = argc;
+ /* Set the address space limit as high as it will go, since we make
+ a lot of very large mappings. */
+ getrlimit(RLIMIT_AS, &rlim);
+ rlim.rlim_cur = rlim.rlim_max;
+ setrlimit(RLIMIT_AS, &rlim);
+
/* move onto another stack so we can play with the main one */
ume_go((addr_t)hoops, (addr_t)stack + sizeof(stack));
|
|
From: Jeremy F. <je...@go...> - 2004-03-09 00:52:04
|
CVS commit by fitzhardinge:
Cope with strange templated symbol names containing quoted ':'.
M +30 -40 vg_stabs.c 1.8
--- valgrind/coregrind/vg_stabs.c #1.7:1.8
@@ -403,10 +403,31 @@ static UInt atou(Char **pp, Int base)
}
-/* Skip to end of name (':'); "::" in the name indicate nesting, and
- are included within the name */
-static Char *nested_name(Char *p) {
- while(*p && (p[0] != ':' || p[1] == ':')) {
- if (*p == ':')
+/* Skip a ':'-delimited name which may have ::, 'char' or other things in
+ <> brackets */
+static Char *templ_name(Char *p)
+{
+ Int brac = 0;
+
+ for(;;) {
+ if (*p == '<')
+ brac++;
+ if (*p == '>')
+ brac--;
+ /* skip quoted character (note, it could be anything, even a
+ literal \0)
+
+ XXX This is a complete botch; we can't do anything sane here,
+ like support \-quoting, because gcc doesn't seem to generate
+ it, and even if it did, we wouldn't know what "'\'" means -
+ the begining of '\'' or a char in itself ('\\')?
+ */
+ if (brac && p[0] == '\'' && p[2] == '\'')
+ p += 3;
+ if (*p == ':') {
+ if (brac && p[1] == ':')
p++;
+ else
+ break;
+ }
p++;
}
@@ -669,22 +690,8 @@ static SymType *stabtype_parser(SegInfo
case 'x': { /* reference to undefined type */
/* 'x' ('s' | 'u' | 'e') NAME ':' */
- Int brac = 0; /* < > brackets in type */
Char kind = *p++; /* get kind */
Char *name = p;
- /* name is delimited by : except for :: within <> */
- for(;;) {
- if (*p == '<')
- brac++;
- if (*p == '>')
- brac--;
- if (*p == ':') {
- if (brac && p[1] == ':')
- p += 1;
- else
- break;
- }
- p++;
- }
+ p = templ_name(name);
EXPECT(':', "struct/union/enum ref");
@@ -785,23 +792,6 @@ static SymType *stabtype_parser(SegInfo
UInt off, sz;
SymType *fieldty;
- Int templ=0;
-
- /* Skip past field name, which ends with ':' or '::' - but
- '::' can appear within a template-mangled name, so keep
- track of '<' and '>'. */
- end = p;
- while(*end) {
- Char ch = *end++;
- if (ch == '<')
- templ++;
- else if (ch == '>')
- templ--;
- else if (templ == 0 && ch == ':') {
- end--;
- break;
- }
- }
- /* XXX check for *end != ':' */
+ end = templ_name(p);
if (end[1] == ':') {
@@ -981,5 +971,5 @@ static Bool initSym(SegInfo *si, Sym *sy
si, si->stab_typetab, sym, kind, name, name, val);
- ty = nested_name(name);
+ ty = templ_name(name);
len = ty - name;
|