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
(10) |
2
(3) |
3
(25) |
4
(8) |
|
5
(13) |
6
(8) |
7
(9) |
8
(10) |
9
(8) |
10
(13) |
11
(12) |
|
12
|
13
(7) |
14
(8) |
15
(11) |
16
(13) |
17
(13) |
18
(11) |
|
19
(13) |
20
(7) |
21
(1) |
22
(1) |
23
(1) |
24
(8) |
25
(15) |
|
26
(16) |
27
(20) |
28
(17) |
29
(10) |
30
(2) |
|
|
|
From: Potter, B. <Bra...@my...> - 2011-06-13 21:56:22
|
Hey Bjoern, Thanks for responding. ASLR is enabled on my computer; the virtual addresses change in the maps file, but I want a more general solution than disabling ASLR. It might help in the short term as far as comparing the mapping, but I would like to know if there is a way to ensure a 1:1 mapping by looking at something other than the virtual address. My thoughts revolved around enumerating the entries in the maps file as the kernel reserves space for them. The enumerations would be chronological and deterministic (I think). Valgrind would enumerate only the client stack in the same manner. The enumeration would act as a key into both maps files. With the virtual-virtual mapping done, I can associate the simulation's virtual address with the physical address as it would have run natively; I already have the virtual-physical translation done. Does anyone know if this is possible to achieve with the Valgrind framework? I've looked at the aspacemgr-linux.c file, but I don't know where to start. If anyone has any pointers or any pitfalls that I might encounter while trying this (or any of the other multi-core stuff), please let me know. -Brandon ________________________________________ From: Bjoern Doebel [bjo...@go...] Sent: Monday, June 13, 2011 1:42 PM To: Potter, Brandon Cc: val...@li... Subject: Re: [Valgrind-developers] Implementing A Multi-Core Cache Simulator Could it be that you're running into problems with address space layout randomization (ASLR) here? The Linux kernel has it turned on and that means that every time you run a program, its memory layout will differ. If so, you might try turning it off for your use case, see http://superuser.com/questions/127238/how-to-turn-off-aslr-in-ubuntu-9-10 . Then the layouts should only differ in the mappings Valgrind makes for its own use. Hth, Bjoern 2011/6/13 Potter, Brandon <Bra...@my...>: > Hello VG_(developers), > I am attempting to implement multi-core cache simulation under Valgrind. I > have run into a few problems and I wanted to know if there was a way to > match the /proc/self/maps (Valgrind) file onto the /proc/pid/maps file of a > natively executing process. I want to map the information from the Valgrind > simulation onto an actual run. > > I have looked at the address space manager within Coregrind and I am forcing > the core to emit the debug information from the manager. I run into trouble > when I try to compare the two. The Valgrind output does not seem to retain > the [stack], [heap], [syscall], etc. identifiers. Furthermore, I have no > way of correlating the anonymous regions. Ideally, I would like to identify > the virtual addresses between the two on a 1:1 mapping. I realized that it > would be possible to modify the Linux kernel to enumerate the individual > listings, but that's not portable. > Does anyone have an idea about how to approach this problem? I really don't > want to modify a kernel module. It would be best if I could make the > Valgrind client's map look exactly like one from normal execution. > > Thanks, > Brandon Potter > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > |
|
From: Bjoern D. <bjo...@go...> - 2011-06-13 20:42:55
|
Could it be that you're running into problems with address space layout randomization (ASLR) here? The Linux kernel has it turned on and that means that every time you run a program, its memory layout will differ. If so, you might try turning it off for your use case, see http://superuser.com/questions/127238/how-to-turn-off-aslr-in-ubuntu-9-10 . Then the layouts should only differ in the mappings Valgrind makes for its own use. Hth, Bjoern 2011/6/13 Potter, Brandon <Bra...@my...>: > Hello VG_(developers), > I am attempting to implement multi-core cache simulation under Valgrind. I > have run into a few problems and I wanted to know if there was a way to > match the /proc/self/maps (Valgrind) file onto the /proc/pid/maps file of a > natively executing process. I want to map the information from the Valgrind > simulation onto an actual run. > > I have looked at the address space manager within Coregrind and I am forcing > the core to emit the debug information from the manager. I run into trouble > when I try to compare the two. The Valgrind output does not seem to retain > the [stack], [heap], [syscall], etc. identifiers. Furthermore, I have no > way of correlating the anonymous regions. Ideally, I would like to identify > the virtual addresses between the two on a 1:1 mapping. I realized that it > would be possible to modify the Linux kernel to enumerate the individual > listings, but that's not portable. > Does anyone have an idea about how to approach this problem? I really don't > want to modify a kernel module. It would be best if I could make the > Valgrind client's map look exactly like one from normal execution. > > Thanks, > Brandon Potter > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > |
|
From: Christian B. <bor...@de...> - 2011-06-13 20:38:47
|
Nightly build on sless390 ( SUSE Linux Enterprise Server 11 SP1 gcc 4.3.4 on z196 (s390x) ) Started at 2011-06-13 22:10:01 CEST Ended at 2011-06-13 22:38:36 CEST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 476 tests, 6 stderr failures, 0 stdout failures, 3 stderrB failures, 0 stdoutB failures, 0 post failures == gdbserver_tests/mcbreak (stderrB) gdbserver_tests/mcclean_after_fork (stderrB) gdbserver_tests/mssnapshot (stderrB) none/tests/faultstatus (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc23_bogus_condwait (stderr) drd/tests/tc04_free_lock (stderr) drd/tests/tc09_bad_unlock (stderr) drd/tests/tc23_bogus_condwait (stderr) |
|
From: Christian B. <bor...@de...> - 2011-06-13 20:38:26
|
Nightly build on fedora390 ( Fedora 13/14/15 mix with gcc 3.5.3 on z196 (s390x) ) Started at 2011-06-13 22:10:01 CEST Ended at 2011-06-13 22:37:33 CEST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 476 tests, 6 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc23_bogus_condwait (stderr) drd/tests/tc04_free_lock (stderr) drd/tests/tc09_bad_unlock (stderr) drd/tests/tc23_bogus_condwait (stderr) |
|
From: Potter, B. <Bra...@my...> - 2011-06-13 20:02:36
|
Hello VG_(developers), I am attempting to implement multi-core cache simulation under Valgrind. I have run into a few problems and I wanted to know if there was a way to match the /proc/self/maps (Valgrind) file onto the /proc/pid/maps file of a natively executing process. I want to map the information from the Valgrind simulation onto an actual run. I have looked at the address space manager within Coregrind and I am forcing the core to emit the debug information from the manager. I run into trouble when I try to compare the two. The Valgrind output does not seem to retain the [stack], [heap], [syscall], etc. identifiers. Furthermore, I have no way of correlating the anonymous regions. Ideally, I would like to identify the virtual addresses between the two on a 1:1 mapping. I realized that it would be possible to modify the Linux kernel to enumerate the individual listings, but that's not portable. Does anyone have an idea about how to approach this problem? I really don't want to modify a kernel module. It would be best if I could make the Valgrind client's map look exactly like one from normal execution. Thanks, Brandon Potter |
|
From: <sv...@va...> - 2011-06-13 13:41:53
|
Author: sewardj Date: 2011-06-13 14:36:59 +0100 (Mon, 13 Jun 2011) New Revision: 11813 Log: Add rough list of bugs that have been fixed since 3.6.1 (74, + 3 n-i-bz, probably some more I missed) Modified: trunk/NEWS Modified: trunk/NEWS =================================================================== --- trunk/NEWS 2011-06-13 13:14:00 UTC (rev 11812) +++ trunk/NEWS 2011-06-13 13:36:59 UTC (rev 11813) @@ -15,7 +15,234 @@ reasonably well on z9 and later models. See README.s390 for more details. +bugs fixed (last update 11 June 2011): +* don't be spooked by libxul.so linked with gold (rXXXX) +* don't be spooked by libraries mashed by elfhack# (rXXXX) +* cachegrind/callgrind: handle CPUID information for Core iX Intel + CPUs that with non-power-of-2 sizes (also AMDs) + +243404 Port to zSeries +Fixed 3.7 + +265762 make public VEX headers compilable by G++ 3.x +Fixed 3.7 + +265771 assertion in jumps.c (r11523) fails with glibc-2.3 +Fixed 3.7 + +266753 valgrind's configure script does not give the user the option + to not use QtCore +fixed, apparently + +266931 gen_insn_test.pl is broken +fixed + +266961 ld-linux.so.2 i?86-linux strlen issues +fixed + +266990 setns instruction causes false positive +fixed + +243935 Helgrind: implementation of ANNOTATE_HAPPENS_BEFORE() / + AFTER() is not correct +fixed, r11624 + +247223 non-x86: Suppress warning: 'regparm' attribute directive + ignored +fixed + + +267383 Assertion 'vgPlain_strlen(dir) + vgPlain_strlen(file) + 1 < + 256' failed. +fixed + +267413 Assertion 'DRD_(g_threadinfo)[tid].synchr_nesting >= 1' + failed. +fixed + +210935 port valgrind.h (not valgrind) to win32 so apps run under + wine can make client requests +afaict, this was fixed in 3.6.1 but is not listed in NEWS + +267488 regtest: darwin support for 64-bit build +fixed + +267552 SIGSEGV (misaligned_stack_error) with DRD, but not with other + tools +fixed, but is the next one also fixed? + +267630 Add support for IBM Power ISA 2.06 -- stage 1 +fixed + +267819 Add client request for informing the core about reallocation +fixed + +267968 drd: drd_thread.c:567 (vgDrd_thread_set_joinable): Assertion + '0 <= (int)tid && tid < DRD_N_THREADS && tid != DRD_INVALID_THREADID' + failed. +fixed + +214223 valgrind SIGSEGV on startup gcc 4.4.1 ppc32 (G4) Ubuntu 9.10 == +259977 Valgrind segfaults doing __builtin_longjmp +fixed + +268792 - valgrind seg faults on startup when compiled with Xcode 4 compilers... +267769 - Darwin: memcheck triggers segmentation fault +274784 - valgrind ls -l or any other valgrind call(even without parameters) results in Segmentation Fault +267342 - segmentation fault on Mac OS 10.6 +271337 - Valgrind segfaults on MacOS X +270309 - valgrind crash on startup +269641 - valgrind segfaults immediately (segmentation fault) +267997 MacOSX: 64-bit valgrind segfaults on launch when built with + Xcode 4.0.1 +fixed + +264800 testcase compile failure on zseries +fixed + +265762 - make public VEX headers compilable by G++ 3.x +fixed + +268513] New: missed optimizations in fold_Expr +fixed + +253206 - Some fixes for the faultstatus testcase +fixed + +268619 - s390x: fpr - gpr transfer facility +fixed + +268620 - s390x: reconsider "long displacement" requirement +fixed + +268621 - s390x: improve IR generation for XC +fixed + +255223 - [PATCH] capget testcase fails when running as root +fixed + +268715 - s390x: FLOGR is not universally available +fixed + +268930 - s390x: MHY is not universally available +fixed + +269078 - [PATCH] vex: arm->IR: unhandled instruction SUB (SP minus +immediate/register) +fixed + +269079 - [PATCH] Support ptrace system call on ARM +fixed + +269144 - missing "Bad option" error message +fixed + +269209] New: [PATCH] conditional load and store facility (z196) +fixed + +269354] New: Shift by zero on x86 can incorrectly clobber CC_NDEP +(with patch) +fixed + +256726 - Helgrind tests have broken inline asm +fixed + +269736 - s390x: minor code generation tweaks +fixed + +256703 - xlc_dbl_u32.c testcase broken +fixed + +272986 - gcc-4.6 warnings with valgrind.h == +269778] New: valgrind.h: swap roles of VALGRIND_DO_CLIENT_REQUEST() +and VALGRIND_DO_CLIENT_REQUEST_EXPR() +fixed + +269863 - s390x: remove unused function parameters +fixed + +269864 - s390x: tweak s390_emit_load_cc +fixed + +270115] New: s390x: rewrite some testcases +fixed + +270082 - s390x: [PATCH] Make sure to point the PSW address to the next +address on SIGILL +fixed + +270794 - New IBM POWER7 support patch causes regression in none/tests +fixed + +270851 - New IBM POWER7 fcfidus instruction causes memcheck to fail +fixed + +270856 - New IBM POWER7 xsnmaddadp instruction causes memcheck to fail +on 32bit app +fixed + +270959 - s390x: invalid use of R0 as base register +fixed + +271042 - VSX configure check fails when it should not +fixed + +271043 - Valgrind build fails with assembler error on ppc64 with +binutils 2.21 +fixed + +271259 - s390x: fix code confusion +fixed + +271385 - s390x: Implement Ist_MBE +fixed + +271501 - s390x : misc cleanups +fixed + +271504 - s390x: promote likely and unlikely +fixed + +271579 - ppc: using wrong enum type +fixed + +271730 - [PATCH] Fix bug when checking ioctls: duplicate check +fixed + +271779 - s390x: provide clock instructions like STCK +fixed + +271799 - Darwin: ioctls without an arg report a memory error +fixed + +271820 - arm: fix type confusion +fixed + +272067 - s390x: fix DISP20 macro +fixed + +272615 - A typo in debug output in mc_leakcheck.c +fixed + +272661 - callgrind_annotate chokes when run from paths containing +regex metacharacters +fixed + +272955 - Unhandled syscall error for pwrite64 on ppc64 arch +fixed + +274447] New: WARNING: unhandled syscall: 340 +fixed + +275148] New: configure FAIL with glibc-2.14 +fixed + +275151] New: Fedora 15 / glibc-2.14 'make regtest' FAIL +fixed + + + Release 3.6.1 (16 February 2011) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3.6.1 is a bug fix release. It adds support for some SSE4 |
|
From: <sv...@va...> - 2011-06-13 13:25:01
|
Author: sewardj
Date: 2011-06-13 14:14:00 +0100 (Mon, 13 Jun 2011)
New Revision: 11812
Log:
Try to handle LL caches which are of size 50% above a power of 2 (eg,
6MB, 12MB) and have a non-power-of-2 number of sets.
Modified:
trunk/cachegrind/cg-x86-amd64.c
trunk/coregrind/m_libcbase.c
trunk/include/pub_tool_libcbase.h
Modified: trunk/cachegrind/cg-x86-amd64.c
===================================================================
--- trunk/cachegrind/cg-x86-amd64.c 2011-06-10 20:29:27 UTC (rev 11811)
+++ trunk/cachegrind/cg-x86-amd64.c 2011-06-13 13:14:00 UTC (rev 11812)
@@ -464,6 +464,59 @@
D1c->size *= 1024;
LLc->size *= 1024;
+ /* If the LL cache config isn't something the simulation functions
+ can handle, try to adjust it so it is. Caches are characterised
+ by (total size T, line size L, associativity A), and then we
+ have
+
+ number of sets S = T / (L * A)
+
+ The required constraints are:
+
+ * L must be a power of 2, but it always is in practice, so
+ no problem there
+
+ * A can be any value >= 1
+
+ * T can be any value, but ..
+
+ * S must be a power of 2.
+
+ That sometimes gives a problem. For example, some Core iX based
+ Intel CPUs have T = 12MB, A = 16, L = 64, which gives 12288
+ sets. The "fix" in this case is to increase the associativity
+ by 50% to 24, which reduces the number of sets to 8192, making
+ it a power of 2. That's what the following code does (handing
+ the "3/2 rescaling case".) We might need to deal with other
+ ratios later (5/4 ?).
+
+ The "fix" is "justified" (cough, cough) by alleging that
+ increases of associativity above about 4 have very little effect
+ on the actual miss rate. It would be far more inaccurate to
+ fudge this by changing the size of the simulated cache --
+ changing the associativity is a much better option.
+ */
+ if (LLc->size > 0 && LLc->assoc > 0 && LLc->line_size > 0) {
+ Long nSets = (Long)LLc->size / (Long)(LLc->line_size * LLc->assoc);
+ if (/* stay sane */
+ nSets >= 4
+ /* nSets is not a power of 2 */
+ && VG_(log2_64)( (ULong)nSets ) == -1
+ /* nSets is 50% above a power of 2 */
+ && VG_(log2_64)( (ULong)((2 * nSets) / (Long)3) ) != -1
+ /* associativity can be increased by exactly 50% */
+ && (LLc->assoc % 2) == 0
+ ) {
+ /* # sets is 1.5 * a power of two, but the associativity is
+ even, so we can increase that up by 50% and implicitly
+ scale the # sets down accordingly. */
+ Int new_assoc = LLc->assoc + (LLc->assoc / 2);
+ VG_(dmsg)("warning: pretending that LL cache has associativity"
+ " %d instead of actual %d\n", new_assoc, LLc->assoc);
+ LLc->assoc = new_assoc;
+ }
+ }
+
return ret;
}
Modified: trunk/coregrind/m_libcbase.c
===================================================================
--- trunk/coregrind/m_libcbase.c 2011-06-10 20:29:27 UTC (rev 11811)
+++ trunk/coregrind/m_libcbase.c 2011-06-13 13:14:00 UTC (rev 11812)
@@ -794,6 +794,15 @@
return -1;
}
+/* Ditto for 64 bit numbers. */
+Int VG_(log2_64) ( ULong x )
+{
+ Int i;
+ for (i = 0; i < 64; i++) {
+ if ((1ULL << i) == x) return i;
+ }
+ return -1;
+}
// Generic quick sort.
void VG_(ssort)( void* base, SizeT nmemb, SizeT size,
Modified: trunk/include/pub_tool_libcbase.h
===================================================================
--- trunk/include/pub_tool_libcbase.h 2011-06-10 20:29:27 UTC (rev 11811)
+++ trunk/include/pub_tool_libcbase.h 2011-06-13 13:14:00 UTC (rev 11812)
@@ -181,10 +181,13 @@
extern void VG_(ssort)( void* base, SizeT nmemb, SizeT size,
Int (*compar)(void*, void*) );
-/* Returns the base-2 logarithm of x. Returns -1 if x is not a power
- of two. Nb: VG_(log2)(1) == 0. */
+/* Returns the base-2 logarithm of a 32 bit unsigned number. Returns
+ -1 if it is not a power of two. Nb: VG_(log2)(1) == 0. */
extern Int VG_(log2) ( UInt x );
+/* Ditto for 64 bit unsigned numbers. */
+extern Int VG_(log2_64)( ULong x );
+
// A pseudo-random number generator returning a random UInt. If pSeed
// is NULL, it uses its own seed, which starts at zero. If pSeed is
// non-NULL, it uses and updates whatever pSeed points at.
|