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
(15) |
2
(17) |
3
(23) |
4
(13) |
5
(7) |
6
(8) |
7
(9) |
|
8
(8) |
9
(31) |
10
(31) |
11
(19) |
12
(11) |
13
(38) |
14
(14) |
|
15
(8) |
16
(11) |
17
(7) |
18
(17) |
19
(12) |
20
(12) |
21
(17) |
|
22
(19) |
23
(33) |
24
(42) |
25
(37) |
26
(23) |
27
(27) |
28
(27) |
|
29
(16) |
30
(52) |
31
(33) |
|
|
|
|
|
From: Julian S. <js...@ac...> - 2004-08-25 23:33:03
|
> And since Valgrind spends the majority of its time in code it generates > itself, any effect will be much smaller than for more normal programs... > therefore, I'm inclined to stop using -fomit-fp. I agree in general. However, V does spend (I assume) quite a lot of time in small tool-supplied helper functions such as MC_(helperc_LOADV4). And it would be a shame to make those run more slowly. That said, perhaps the performance effects are in the noise, and doing -fomit-fp in some places and not others just wasn't worth the hassle. That would be nice if it was true; but I don't have numbers. J |
|
From: Jeremy F. <je...@go...> - 2004-08-25 22:04:30
|
On Wed, 2004-08-25 at 22:43 +0100, Nicholas Nethercote wrote: > Another possibility is to poke around with mmaps, and see where they stop > succeeding. Unfortunately, this kind of trashes the code/data that is > already used in the address space, which gives unpredictable results. > > Any other ideas? > > This is with respect to determining (at configure-time) where stage2 > should go. I've been thinking about this, but there isn't a good clean way to do it. The best I can come up with is to scan /proc/self/maps for the highest address present, then try to create mmaps from there up, and use a binary search to see how much space is available above the top mapping. I think this should probably be done in stage1 dynamically rather than fixed at config-time, since different processes can have different address-space configurations (and certainly different kernels can). J |
|
From: Nicholas N. <nj...@ca...> - 2004-08-25 21:43:29
|
Hi, What's a good way to find the highest user-space address? One possibility is to look at the address of a stack variable, and round up a bit. This is really simple but assumes that the stack is at the top of the user-space. Another possibility is to poke around with mmaps, and see where they stop succeeding. Unfortunately, this kind of trashes the code/data that is already used in the address space, which gives unpredictable results. Any other ideas? This is with respect to determining (at configure-time) where stage2 should go. thanks N |
|
From: Tom H. <th...@cy...> - 2004-08-25 18:58:09
|
CVS commit by thughes:
If we return from a signal handler to a thread that was waiting to
rendezvous with another thread before the signal arrived then check
whether the rendezvous is now complete or we may deadlock.
CCMAIL: 773...@bu...
M +9 -0 vg_scheduler.c 1.171
--- valgrind/coregrind/vg_scheduler.c #1.170:1.171
@@ -98,4 +98,5 @@ static void do_client_request ( ThreadId
static void scheduler_sanity ( void );
static void do_pthread_cond_timedwait_TIMEOUT ( ThreadId tid );
+static void maybe_rendezvous_joiners_and_joinees ( void );
/* Stats. */
@@ -619,4 +620,12 @@ void handle_signal_return ( ThreadId tid
restart_blocked_syscalls = VG_(signal_returns)(tid);
+ /* If we were interrupted in the middle of a rendezvous
+ then check the rendezvous hasn't completed while we
+ were busy handling the signal. */
+ if (VG_(threads)[tid].status == VgTs_WaitJoiner ||
+ VG_(threads)[tid].status == VgTs_WaitJoinee ) {
+ maybe_rendezvous_joiners_and_joinees();
+ }
+
if (restart_blocked_syscalls)
/* Easy; we don't have to do anything. */
|
|
From: Nicholas N. <nj...@ca...> - 2004-08-25 17:00:09
|
On Tue, 24 Aug 2004, Paul Mackerras wrote:
>>> Well, this test in do_brk() is wrong:
>>>
>>> if (PGROUNDDN(newbrk) != PGROUNDDN(VG_(brk_limit))) {
>>>
>>> That triggers when the break goes from (e.g.) 0x10010fff to
>>> 0x10011000, and the code in there concludes (correctly) that no more
>>> memory is needed, and updates VG_(brk_limit) to 0x10011000. Then when
>>> we raise the break to 0x10011001, that test doesn't trigger and so we
>>> don't allocate any more memory, but we return the new break.
>>
>> What should the test say? Can you make a patch?
>
> Sure, basically the test should be using PGROUNDUP rather than
> PGROUNDDN. This patch fixes it. The test program runs to completion
> now.
committed, thanks
N
|
|
From: Nicholas N. <nj...@ca...> - 2004-08-25 16:55:51
|
On Fri, 20 Aug 2004, Samofatov, Nickolay wrote: >> If you're feeling adventurous, you could try inserting >> VG_(printf)() calls (or OINK() calls) in >> vg_signals.c:vg_sync_signalhandler() and try to work out if >> something is going wrong in there. Particularly around line >> 2106, where the comment says "extend the stack segment". >> >> You could also make a bug report in Bugzilla. > > Valgrind is not a trivial piece of engineering artwork. I can do some > small fixes, like adding support for missing syscalls or feature to > create program core dumps automatically when problems are . > But hardcore Valgrind debugging is currently out of the area of my > competence. But you know how use printf(), right? I was suggesting sticking a few into that part of the code in an attempt to work out on which line the seg fault occurs. Easiest is with OINK() -- put a line OINK(1); before a line, put OINK(2); after it, and if Valgrind crashes printing the first OINK but not the second, you know it's that line that is causing the seg fault. You don't have to understand Valgrind at all to do that, since I've told you which code region to put them in. > You already said that such bugs are difficult to fix without > reproducable test case. If you would like to fix this problem I can hand > reproducable test case for it to you. There will be 10 MB of source code > and 42 MB database dump. Error happens after 10-15 minutes of test > runtime. 15 minutes? That does make searching with printf() more difficult... N |
|
From: Nicholas N. <nj...@ca...> - 2004-08-25 16:17:11
|
CVS commit by nethercote:
Change things so that stage2's location is controlled by a single variable.
M +9 -2 Makefile.am 1.77
M +1 -1 stage1.c 1.17
--- valgrind/coregrind/Makefile.am #1.76:1.77
@@ -8,5 +8,6 @@
inplacedir = $(top_builddir)/.in_place
-AM_CPPFLAGS = $(add_includes) -DVG_LIBDIR="\"$(valdir)"\"
+AM_CPPFLAGS = $(add_includes) -DVG_LIBDIR="\"$(valdir)"\" \
+ -DKICKSTART_BASE=$(KICKSTART_BASE)
AM_CFLAGS = $(WERROR) -Winline -Wall -Wshadow -O -fno-omit-frame-pointer \
@PREFERRED_STACK_BOUNDARY@ -g -DELFSZ=32
@@ -41,4 +42,10 @@
valgrind_LDADD=
+# Where stage2 will be put.
+# Nb: Hard-wiring this sucks. A configure-time test would be better. A
+# load-time test would be even better, but would require building stage2 in
+# a position-independent way...
+KICKSTART_BASE=0xb0000000
+
stage2_SOURCES = \
ume.c \
@@ -81,5 +88,5 @@
stage2_DEPENDENCIES = $(srcdir)/valgrind.vs x86/stage2.lds
stage2_LDFLAGS=-Wl,--export-dynamic -Wl,-e,_ume_entry -g \
- -Wl,-defsym,kickstart_base=0xb0000000 \
+ -Wl,-defsym,kickstart_base=$(KICKSTART_BASE) \
-Wl,-T,x86/stage2.lds \
-Wl,-version-script $(srcdir)/valgrind.vs
--- valgrind/coregrind/stage1.c #1.16:1.17
@@ -181,5 +181,5 @@ static void hoops(void)
- something else?
*/
- info.map_base = 0xb1000000;
+ info.map_base = KICKSTART_BASE + 0x01000000;
info.argv = NULL;
|
|
From: Nicholas N. <nj...@ca...> - 2004-08-25 13:43:52
|
CVS commit by nethercote:
Fix problem with brk(). Thanks to Paull Mackerras for the patch.
Added a regression test for it.
A memcheck/tests/brk2.c 1.1 [POSSIBLY UNSAFE: printf] [no copyright]
A memcheck/tests/brk2.stderr.exp 1.1
A memcheck/tests/brk2.vgtest 1.1
M +5 -3 coregrind/vg_syscalls.c 1.129
M +3 -1 memcheck/tests/Makefile.am 1.41
--- valgrind/coregrind/vg_syscalls.c #1.128:1.129
@@ -901,4 +901,6 @@ static Addr do_brk(Addr newbrk)
static const Bool debug = False;
Segment *seg;
+ Addr current, newaddr;
+
if (debug)
@@ -923,7 +925,7 @@ static Addr do_brk(Addr newbrk)
return VG_(brk_limit);
- if (PGROUNDDN(newbrk) != PGROUNDDN(VG_(brk_limit))) {
- Addr current = PGROUNDUP(VG_(brk_limit));
- Addr newaddr = PGROUNDUP(newbrk);
+ current = PGROUNDUP(VG_(brk_limit));
+ newaddr = PGROUNDUP(newbrk);
+ if (newaddr != current) {
/* new brk in a new page - fix the mappings */
--- valgrind/memcheck/tests/Makefile.am #1.40:1.41
@@ -19,4 +19,5 @@
badrw.stderr.exp badrw.vgtest \
brk.stderr.exp brk.vgtest \
+ brk2.stderr.exp brk2.vgtest \
buflen_check.stderr.exp buflen_check.vgtest \
clientperm.stderr.exp \
@@ -78,5 +79,5 @@
check_PROGRAMS = \
- badaddrvalue badfree badjump badloop badrw brk buflen_check \
+ badaddrvalue badfree badjump badloop badrw brk brk2 buflen_check \
clientperm custom_alloc \
doublefree error_counts errs1 exitprog execve execve2 \
@@ -101,4 +102,5 @@
badrw_SOURCES = badrw.c
brk_SOURCES = brk.c
+brk2_SOURCES = brk2.c
buflen_check_SOURCES = buflen_check.c
clientperm_SOURCES = clientperm.c
|
|
From: Nicholas N. <nj...@ca...> - 2004-08-25 13:33:31
|
CVS commit by nethercote:
Remove three unnecessary compile-time warnings.
Two were trivial. The one for strncmp is slightly trickier; you have to be
careful with the signedness of chars when comparing them... but the code
already casts s1 and s2 to (unsigned char*) before comparing them, so it's not
a problem.
M +5 -6 mac_replace_strmem.c 1.14
--- valgrind/memcheck/mac_replace_strmem.c #1.13:1.14
@@ -156,9 +156,9 @@ char* strcat ( char* dst, const char* sr
}
-char* strncat ( char* dst, const char* src, int n )
+char* strncat ( char* dst, const char* src, unsigned int n )
{
const Char* src_orig = src;
Char* dst_orig = dst;
- Int m = 0;
+ UInt m = 0;
while (*dst) dst++;
@@ -210,9 +210,9 @@ char* strcpy ( char* dst, const char* sr
}
-char* strncpy ( char* dst, const char* src, int n )
+char* strncpy ( char* dst, const char* src, unsigned int n )
{
const Char* src_orig = src;
Char* dst_orig = dst;
- Int m = 0;
+ UInt m = 0;
while (m < n && *src) { m++; *dst++ = *src++; }
@@ -226,6 +226,5 @@ char* strncpy ( char* dst, const char* s
}
-int strncmp ( const unsigned char* s1, const unsigned char* s2,
- unsigned int nmax )
+int strncmp ( const char* s1, const char* s2, unsigned int nmax )
{
unsigned int n = 0;
|
|
From: Tom H. <th...@cy...> - 2004-08-25 13:25:36
|
CVS commit by thughes:
Removed comma at the end of an enumerator list - this is allowed
in C99 but not in C89 except as a GNU extension so it's probably
best not to rely on it.
Patch from Jeroen N. Witmond <jn...@xs...>.
M +1 -1 valgrind.h 1.27
--- valgrind/include/valgrind.h #1.26:1.27
@@ -172,5 +172,5 @@ typedef
/* Allow printfs to valgrind log. */
VG_USERREQ__PRINTF = 0x1401,
- VG_USERREQ__PRINTF_BACKTRACE = 0x1402,
+ VG_USERREQ__PRINTF_BACKTRACE = 0x1402
} Vg_ClientRequest;
|
|
From: Nicholas N. <nj...@ca...> - 2004-08-25 12:36:35
|
Hi, I've rejigged my file/dir structure proposal, and started reshaping Paul's x86-abstraction patch accordingly. You can grab see the basics in a tarball at www.cl.cam.ac.uk/~njn25/vg-arch.tar.bz2 and the diff (which is hard to read and doesn't account for the new files and file renamings) is at www.cl.cam.ac.uk/~njn25/vg-arch.diff I've left lots of Paul's patch out; this tarball contains just enough of it to show how the structure works. We've discussed arch-, os- and platform-specific code; this version only contains arch- abstraction, which is enough to see how things work. So, for example, there is stuff in coregrind/x86/ but there is no coregrind/linux/ or coregrind/x86-linux/ directories yet. Note that a few header filenames have changed, notably: vg_include.h --> core.h vg_skin.h --> tool.h vg_constants.h --> core_asm.h vg_constants_skin.h --> tool_asm.h And there are various new headers. include/x86/ is new as well. As for how these proposed file renamings would be done in CVS, I think just cvs removing then cvs adding them under the new names would do. We'd lose the direct log history, but it would still be available under the old names. We've already had this happen once when vg_skin.h became vg_skin.h.base, and it's only another four files. The alternatives (either hacking the repository, or switching to something better than CVS) are sufficiently painful/controversial in the short-term that I'd prefer this, which has the virtue of being able to be done easily and quickly. I ended up using -I instead of symlinks to select the right $ARCH/ directory, because that ended up being the easiest to get right. I include below a revised description of how it works; it has significant differences to my first version, and is hopefully substantially clearer, so I recommend reading it again. Note that this tarball includes changes involved with factoring out the common Makefile.am parts into multiple files. These are currently in the top-level directory, perhaps they could go in a dedicated directory to reduce clutter. I plan to separate that part of the patch out and commit it first, probably after 2.2.0 is released. After that, once we've agreed on the exact file/dir structure, I'd like to start the restructuring in earnest (starting with completing the changes in Paul's patch) since all arch port work depends on this (eg. Paul's PPC port, my nascent x86-64 port). All feedback welcome. Thanks. N Proposal -------- Terminology: A "platform" is a specific $ARCH/$OS pair. For every arch and OS, there will be 4 code parts, in order of genericity: 1. some generic code 2a. some arch-specific, OS-independent code (aka $ARCH, arch) 2b. some arch-independent, OS-specific code (aka $OS, os) 3. some platform-specific code (aka $ARCH-$OS, arch-os) 2a, 2b and 3 are all "non-generic". The keys ideas are: - to very carefully identify which category all code belongs to - to minimise the interface between generic and non-generic code - to minimise code duplication by pushing code into the most generic code part possible Abstract directory structure (where the right hand side shows what fns/vars/macros would go in each file): valgrind/ memcheck/ cachegrind/ # etc, other tools include/ tool.h (was vg_skin.h) tool_asm.h (was vg_constants_skin.h) x86/ tool_arch.h ARCH_STACK_POINTER(?), REGPARM, FIRST_ARCH_REG linux/ x86-linux/ unistd.h? coregrind/ core.h (was vg_include.h) includes decls of arch/OS/platform-specific fns/vars, eg. VGA_(load_state)(), IR decode/encode decls, VG_(do_syscall)(), VG_(arch_deliver_signal)()(?) core_asm.h (was vg_constants.h) x86/ (all contents become libarch.a) # interface core_arch.h arch_thread_t core_arch_asm.h VG_PATCHME_CALLSZ, VG_CODE_OFFSET, INSTR_MIN_SIZE # implementation (exact file names don't matter) x86.h VG_SIZE_OF_SSESTATE(?), VG_(do_useseg)() decl, VG_(helper_*) decl, VGOFF_(m_eax) x86_state.c VG_(arch_load_state)() definition, VG_(helper_*) def VGOFF_(m_eax) def x86_asm.S x86_ldt.c VG_(do_useseg)() def x86_to_IR.c # x86 disassembly to IR stuff x86_from_IR.c # x86 IR codegen stuff linux/ #interface core_os.h core_os_asm.h # implementation vg_kerneliface.h types generic for all Linux platforms(?) etc. x86-linux/ # interface core_platform.h ARCH_SYSCALL_NUM core_platform_asm.h # implementation x86-linux_asm.S VG_(do_syscall)() definition x86-linux_signal.c VG_(arch_deliver_signal)() definition(?) x86-linux_vki.h x86/Linux-specific kernel types[or interface?] Interfacing .c/.S files with .h files: - all core C files include core.h - all core asm files include core_asm.h - all tool C files include tool.h - all tool asm files include tool_asm.h - The header hierarchy itself is based around the following rules: - core headers include tool headers - generic headers include arch/OS/platform headers - C headers include asm headers This gives the following hierarchy (only showing 'arch' headers, not 'os' or 'platform' headers), where arrows indicate inclusion: (tool_arch_asm.h?) <------- core_arch_asm.h ^ ^ ^ ^ / \ / \ / \ / \ tool_asm.h <---\---------- core_asm.h \ ^ \ ^ \ \ tool_arch.h <---------\---- core_arch.h \ ^ \ ^ \ / \ / \ / \ / tool.h <------------------ core.h (This is sufficiently complex that clear names are important; this is why I'm suggesting changing the old names vg_skin.h, vg_constants.h, etc, which make it much harder to see what the headers contain.) Note that core.h contains the *declarations* of arch-specific functions and variables. (The functions/variables are *defined* within $VG_ARCH/.) However, arch-specific macros and types cannot go into core.h, because there is no separation between declaration and definition for macros/types, so they instead go into $VG_ARCH/core_arch.h. tool_arch_asm.h is in parens because I'm not aware of any arch-specific asm macros needed by tools, and so we don't have it at the moment. Actions: - Config-time setup sets $VG_ARCH, $VG_OS, $VG_PLATFORM - using -I with $VG_ARCH et al to select the right arch/OS/platform headers - stage2 built from generic .o files + $VG_ARCH/libarch.a, $VG_OS/libos.a, $VG_PLATFORM/libplatform.a Note that each part's .h is necessarily split into defs and macros; the defs .h can be shared by all sub-dirs, whereas each sub-dir has to provide its own version of every macro. This is because functions/variables can be defined/declared in different places, but macros can't. This is the "minimise duplication" principle at work. At the moment, there is no special treatment of stuff shared between multiple Unixes, or Elf stuff shared between multiple platforms. I imagine having separate unix/ and elf/ subdirs would be fine, and the relevant libarch.a/libos.a/libplatform.a files could be built using any needed parts in them. For tools that need to do non-generic things (which should be avoided as much as possible, but may be inevitable in small amounts, esp. for Memcheck) parts of the structure can be mirrored as necessary within the tool/ (eg. memcheck/) directory. |
|
From: Andrew H. <ap...@re...> - 2004-08-25 12:23:56
|
Nicholas Nethercote writes: > > I guess the conclusion is that -fomit-fp does make things smaller when no > debug info is present, but not by much. And that this is because although > fewer instructions are generated, those generated are on average longer... You might like to try -momit-leaf-frame-pointer. Andrew. |
|
From: Nicholas N. <nj...@ca...> - 2004-08-25 11:57:28
|
CVS commit by nethercote:
Fix symlinking -- the old code worked, but worked for the wrong reason; the
bit before "$(subdir)" has to specify the path from .in_place/ to the root.
It just so happened that $(top_builddir) was the same for all directories at
the same level in the hierarchy as .in_place/ (ie. one deep).
(I haven't bothered changing it in all the tool Makefile.am files, because I'll
do that when I factor out all their common bits into a single file, be it
before or after 2.2.0 is released.)
M +1 -1 Makefile.am 1.76
--- valgrind/coregrind/Makefile.am #1.75:1.76
@@ -155,5 +155,5 @@
to=$(inplacedir)/$$(echo $$i | sed 's,libpthread.so,libpthread.so.0,'); \
rm -f $$$to; \
- ln -sf $(top_builddir)/$(subdir)/$$i $$to; \
+ ln -sf ../$(subdir)/$$i $$to; \
done
|
|
From: Nicholas N. <nj...@ca...> - 2004-08-25 11:50:58
|
CVS commit by nethercote:
Minor fixups:
- introduce $(inplacedir) like everywhere else
- valgrind.spec doesn't need to be included in "make dist", because it gets
built from valgrind.spec.in at configure-time.
M +7 -6 Makefile.am 1.69
--- valgrind/Makefile.am #1.68:1.69
@@ -19,4 +19,5 @@
valdir = $(libdir)/valgrind
+inplacedir = $(top_builddir)/.in_place
SUPP_FILES = \
@@ -44,5 +45,5 @@
README_PACKAGERS \
README_MISSING_SYSCALL_OR_IOCTL TODO \
- valgrind.spec valgrind.spec.in valgrind.pc.in
+ valgrind.spec.in valgrind.pc.in
install-exec-hook:
@@ -52,9 +53,9 @@
all-local:
- mkdir -p $(top_builddir)/.in_place
- rm -f $(addprefix $(top_builddir)/.in_place/,default.supp $(SUPP_FILES))
- ln -s ../default.supp $(top_builddir)/.in_place
- ln -s $(addprefix ../$(top_srcdir)/,$(SUPP_FILES)) $(top_builddir)/.in_place
+ mkdir -p $(inplacedir)
+ rm -f $(addprefix $(inplacedir)/,default.supp $(SUPP_FILES))
+ ln -s ../default.supp $(inplacedir)
+ ln -s $(addprefix ../$(top_srcdir)/,$(SUPP_FILES)) $(inplacedir)
distclean-local:
- rm -rf $(top_builddir)/.in_place
+ rm -rf $(inplacedir)
|
|
From: Nicholas N. <nj...@ca...> - 2004-08-25 11:40:13
|
CVS commit by nethercote:
Putting "dist_" in front of a "_DATA" variable means it is included in "make
dist". This avoids the need to put it in "EXTRA_DIST", and saves a few lines
in all the docs Makefile.am files.
M +2 -2 Makefile.am 1.68
M +1 -3 addrcheck/docs/Makefile.am 1.3
M +1 -3 cachegrind/docs/Makefile.am 1.3
M +1 -3 corecheck/docs/Makefile.am 1.3
M +1 -3 coregrind/docs/Makefile.am 1.5
M +1 -3 docs/Makefile.am 1.4
M +1 -3 helgrind/docs/Makefile.am 1.3
M +1 -3 lackey/docs/Makefile.am 1.3
M +1 -3 massif/docs/Makefile.am 1.2
M +1 -3 memcheck/docs/Makefile.am 1.3
M +1 -3 none/docs/Makefile.am 1.3
--- valgrind/Makefile.am #1.67:1.68
@@ -24,5 +24,5 @@
xfree-3.supp xfree-4.supp
-val_DATA = $(SUPP_FILES) default.supp
+dist_val_DATA = $(SUPP_FILES) default.supp
pkgconfigdir = $(libdir)/pkgconfig
@@ -39,5 +39,5 @@
@PERL@ tests/vg_regtest --all
-EXTRA_DIST = $(val_DATA) \
+EXTRA_DIST = \
FAQ.txt \
ACKNOWLEDGEMENTS \
--- valgrind/addrcheck/docs/Makefile.am #1.2:1.3
@@ -1,5 +1,3 @@
docdir = $(datadir)/doc/valgrind
-doc_DATA = ac_main.html
-
-EXTRA_DIST = $(doc_DATA)
+dist_doc_DATA = ac_main.html
--- valgrind/cachegrind/docs/Makefile.am #1.2:1.3
@@ -1,5 +1,3 @@
docdir = $(datadir)/doc/valgrind
-doc_DATA = cg_main.html cg_techdocs.html
-
-EXTRA_DIST = $(doc_DATA)
+dist_doc_DATA = cg_main.html cg_techdocs.html
--- valgrind/corecheck/docs/Makefile.am #1.2:1.3
@@ -1,5 +1,3 @@
docdir = $(datadir)/doc/valgrind
-doc_DATA = cc_main.html
-
-EXTRA_DIST = $(doc_DATA)
+dist_doc_DATA = cc_main.html
--- valgrind/coregrind/docs/Makefile.am #1.4:1.5
@@ -1,5 +1,3 @@
docdir = $(datadir)/doc/valgrind
-doc_DATA = coregrind_core.html coregrind_intro.html coregrind_tools.html
-
-EXTRA_DIST = $(doc_DATA)
+dist_doc_DATA = coregrind_core.html coregrind_intro.html coregrind_tools.html
--- valgrind/docs/Makefile.am #1.3:1.4
@@ -1,5 +1,3 @@
docdir = $(datadir)/doc/valgrind
-doc_DATA = manual.html
-
-EXTRA_DIST = $(doc_DATA)
+dist_doc_DATA = manual.html
--- valgrind/helgrind/docs/Makefile.am #1.2:1.3
@@ -1,5 +1,3 @@
docdir = $(datadir)/doc/valgrind
-doc_DATA = hg_main.html
-
-EXTRA_DIST = $(doc_DATA)
+dist_doc_DATA = hg_main.html
--- valgrind/lackey/docs/Makefile.am #1.2:1.3
@@ -1,5 +1,3 @@
docdir = $(datadir)/doc/valgrind
-doc_DATA = lk_main.html
-
-EXTRA_DIST = $(doc_DATA)
+dist_doc_DATA = lk_main.html
--- valgrind/massif/docs/Makefile.am #1.1:1.2
@@ -1,5 +1,3 @@
docdir = $(datadir)/doc/valgrind
-doc_DATA = ms_main.html date.gif
-
-EXTRA_DIST = $(doc_DATA)
+dist_doc_DATA = ms_main.html date.gif
--- valgrind/memcheck/docs/Makefile.am #1.2:1.3
@@ -1,5 +1,3 @@
docdir = $(datadir)/doc/valgrind
-doc_DATA = mc_main.html mc_techdocs.html
-
-EXTRA_DIST = $(doc_DATA)
+dist_doc_DATA = mc_main.html mc_techdocs.html
--- valgrind/none/docs/Makefile.am #1.2:1.3
@@ -1,5 +1,3 @@
docdir = $(datadir)/doc/valgrind
-doc_DATA = nl_main.html
-
-EXTRA_DIST = $(doc_DATA)
+dist_doc_DATA = nl_main.html
|
|
From: Nicholas N. <nj...@ca...> - 2004-08-25 11:27:10
|
On Wed, 25 Aug 2004, Julian Seward wrote: > Well, after dodging all those red herrings, what I thought the original > proposition was is that code generated with -fomit-fp runs more slowly > than without. Which sounds a bit unlikely. So does anyone have any > cycle counts with/without -fomit-fp? > > From my days of bzip2 hacking, I seem to remember -fomit-fp made things > run 5% ish faster, which is kinda what you'd expect when increasing the > available integer regs from 6 to 7. Dually, turning on -fpic, which > puts %ebx out of action, aiui, gave a 7% ish speed loss. Perhaps on > modern machines with reg-renaming and a relatively weaker memory > hierarchy, the differences are smaller? And since Valgrind spends the majority of its time in code it generates itself, any effect will be much smaller than for more normal programs... therefore, I'm inclined to stop using -fomit-fp. N |
|
From: Julian S. <js...@ac...> - 2004-08-25 11:23:58
|
> For vgskin_memcheck.so, the biggest of the relevant files: > > normal: 242344 > -fomit-fp: 261268 > > normal stripped: 90588 > -fomit-fp stripped: 90044 > > The difference is 0.6%. > > I guess the conclusion is that -fomit-fp does make things smaller when no > debug info is present, but not by much. And that this is because although > fewer instructions are generated, those generated are on average longer... Well, after dodging all those red herrings, what I thought the original proposition was is that code generated with -fomit-fp runs more slowly than without. Which sounds a bit unlikely. So does anyone have any cycle counts with/without -fomit-fp? =46rom my days of bzip2 hacking, I seem to remember -fomit-fp made things run 5% ish faster, which is kinda what you'd expect when increasing the available integer regs from 6 to 7. Dually, turning on -fpic, which puts %ebx out of action, aiui, gave a 7% ish speed loss. Perhaps on modern machines with reg-renaming and a relatively weaker memory hierarchy, the differences are smaller? J |
|
From: Nicholas N. <nj...@ca...> - 2004-08-25 10:47:43
|
Hi,
First, in Makefile.am we have this:
SUPP_FILES = \
glibc-2.1.supp glibc-2.2.supp glibc-2.3.supp \
xfree-3.supp xfree-4.supp
Note that there is no mention of linux22.supp and linux24.supp. In fact,
those files don't get included in a "make dist". However, since they're
never actually used, that doesn't matter. Looking at their log messages,
they haven't ever been touched in a meaningful way. Why do we have them?
Can we remove them?
Second, we install all the .supp files (except the linux*.supp ones :) in
the $PREFIX/lib/valgrind/. Is this necessary? Would just default.supp
suffice? I guess the question is: does anybody use the individual .supp
files (eg. glibc-2.1.supp) at all?
Thanks.
N
|
|
From: Nicholas N. <nj...@ca...> - 2004-08-25 10:42:47
|
On Wed, 25 Aug 2004, Andrew Haley wrote: > > Ah, I didn't think of that, I think it answers the question... for > > vgskin_lackey.so, I get the following sizes: > > > > normal: 26577 > > -fomit-fp: 27299 > > > > normal stripped: 7780 > > -fomit-fp stripped: 7748 > > > > The stripped versions look as expected, ie. with -fomit-fp it is smaller. > > Only by 0.4%, which is nearly at the level of noise. Is this true of > the other executables as well? For vgskin_memcheck.so, the biggest of the relevant files: normal: 242344 -fomit-fp: 261268 normal stripped: 90588 -fomit-fp stripped: 90044 The difference is 0.6%. I guess the conclusion is that -fomit-fp does make things smaller when no debug info is present, but not by much. And that this is because although fewer instructions are generated, those generated are on average longer... N |
|
From: Andrew H. <ap...@re...> - 2004-08-25 10:37:25
|
Nicholas Nethercote writes:
> On Wed, 25 Aug 2004, Florian Weimer wrote:
>
> >> So why are the total file sizes larger with -fomit-frame-pointer?
> >
> > Have you already ruled out debugging information? Since you compile
> > with -g, this seems the most likely culprit. (If there is not frame
> > pointer, more debugging information is needed to access local
> > variables, so this growth isn't really avoidable.)
>
> Ah, I didn't think of that, I think it answers the question... for
> vgskin_lackey.so, I get the following sizes:
>
> normal: 26577
> -fomit-fp: 27299
>
> normal stripped: 7780
> -fomit-fp stripped: 7748
>
> The stripped versions look as expected, ie. with -fomit-fp it is smaller.
> It's interesting to see this effect, and good to know why it occurs.
Here you are:
/tmp/vgskin_lackey.so-normal
27 .debug_frame 00000144 00000000 00000000 0000418c 2**2
CONTENTS, READONLY, DEBUGGING
/tmp/vgskin_lackey.so-fomitfp
27 .debug_frame 000003f8 00000000 00000000 00004164 2**2
CONTENTS, READONLY, DEBUGGING
|
|
From: Andrew H. <ap...@re...> - 2004-08-25 10:17:36
|
Nicholas Nethercote writes: > On Wed, 25 Aug 2004, Florian Weimer wrote: > > >> So why are the total file sizes larger with -fomit-frame-pointer? > > > > Have you already ruled out debugging information? Since you compile > > with -g, this seems the most likely culprit. (If there is not frame > > pointer, more debugging information is needed to access local > > variables, so this growth isn't really avoidable.) > > Ah, I didn't think of that, I think it answers the question... for > vgskin_lackey.so, I get the following sizes: > > normal: 26577 > -fomit-fp: 27299 > > normal stripped: 7780 > -fomit-fp stripped: 7748 > > The stripped versions look as expected, ie. with -fomit-fp it is smaller. Only by 0.4%, which is nearly at the level of noise. Is this true of the other executables as well? Andrew. |
|
From: Nicholas N. <nj...@ca...> - 2004-08-25 10:13:13
|
On Wed, 25 Aug 2004, Andrew Haley wrote: > > > So why are the total file sizes larger with -fomit-frame-pointer? Do > > > any GCC people know? > > > > One reason might be that accessing relative to stack pointer takes one > > byte more than relative to frame pointer: > > Could be, but 7%? I really want to see those files. I've put them (unstripped) at: www.cl.cam.ac.uk/~njn25/vgskin_lackey.so-normal www.cl.cam.ac.uk/~njn25/vgskin_lackey.so-fomitfp N |
|
From: Nicholas N. <nj...@ca...> - 2004-08-25 10:11:05
|
On Wed, 25 Aug 2004, Florian Weimer wrote: >> So why are the total file sizes larger with -fomit-frame-pointer? > > Have you already ruled out debugging information? Since you compile > with -g, this seems the most likely culprit. (If there is not frame > pointer, more debugging information is needed to access local > variables, so this growth isn't really avoidable.) Ah, I didn't think of that, I think it answers the question... for vgskin_lackey.so, I get the following sizes: normal: 26577 -fomit-fp: 27299 normal stripped: 7780 -fomit-fp stripped: 7748 The stripped versions look as expected, ie. with -fomit-fp it is smaller. It's interesting to see this effect, and good to know why it occurs. On Wed, 25 Aug 2004, Andrew Haley wrote: > Unwind info? I guess not, since it seems to be the debug info. (The code is all C, I should have mentioned that... is unwind info for C++ only? Either way, seems like it doesn't matter.) Thanks very much, everyone! N |
|
From: Andrew H. <ap...@re...> - 2004-08-25 10:08:25
|
Falk Hueffner writes: > Nicholas Nethercote <nj...@ca...> writes: > > > So why are the total file sizes larger with -fomit-frame-pointer? Do > > any GCC people know? > > One reason might be that accessing relative to stack pointer takes one > byte more than relative to frame pointer: Could be, but 7%? I really want to see those files. Andrew. |
|
From: Falk H. <hue...@in...> - 2004-08-25 10:02:03
|
Nicholas Nethercote <nj...@ca...> writes:
> So why are the total file sizes larger with -fomit-frame-pointer? Do
> any GCC people know?
One reason might be that accessing relative to stack pointer takes one
byte more than relative to frame pointer:
int f(int n) { volatile int a[4]; return a[1] + a[2]; }
% gcc -c -O3 test.c && objdump -dr test.o
00000000 <f>:
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: 83 ec 18 sub $0x18,%esp
6: 8b 45 ec mov 0xffffffec(%ebp),%eax
9: 8b 4d f0 mov 0xfffffff0(%ebp),%ecx
c: 01 c8 add %ecx,%eax
e: c9 leave
f: c3 ret
% gcc -fomit-frame-pointer -c -O3 test.c && objdump -dr test.o
00000000 <f>:
0: 83 ec 1c sub $0x1c,%esp
3: 8b 44 24 04 mov 0x4(%esp,1),%eax
7: 8b 4c 24 08 mov 0x8(%esp,1),%ecx
b: 01 c8 add %ecx,%eax
d: 83 c4 1c add $0x1c,%esp
10: c3 ret
--
Falk
|