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
(11) |
|
2
(5) |
3
(11) |
4
(13) |
5
(1) |
6
(15) |
7
(1) |
8
(1) |
|
9
(2) |
10
(4) |
11
(15) |
12
(2) |
13
(12) |
14
(2) |
15
(3) |
|
16
(1) |
17
(16) |
18
(1) |
19
(32) |
20
(19) |
21
(3) |
22
|
|
23
|
24
(4) |
25
|
26
(1) |
27
(19) |
28
(4) |
29
(2) |
|
30
(3) |
|
|
|
|
|
|
|
From: Dirk M. <dm...@gm...> - 2003-11-19 23:18:33
|
On Wednesday 19 November 2003 23:29, Nicholas Nethercote wrote: > Are there instructions somewhere? How's it all work? There is the web interface, which has mostly a self-containing documentation hidden behind all the knobs on the bug forms, see http://bugs.kde.org/queryhelp.cgi There is also a mail interface which is mostly undocumented and a xml query interface (used by offline tools like kbugbuster). Anyway, if there is a more specific question, just ask. Dirk |
|
From: Nicholas N. <nj...@ca...> - 2003-11-19 22:30:32
|
Hi, It seems people are starting to use Bugzilla to report bugs. This is good. I have no idea how to use Bugzilla. This is bad. Are there instructions somewhere? How's it all work? Thanks. N |
|
From: Dirk M. <mu...@kd...> - 2003-11-19 22:08:06
|
CVS commit by mueller:
this should fix compilation on weird kernel 2.6.x installations.
CCMAIL: 68...@bu...
M +4 -4 coregrind/vg_syscalls.c 1.59
M +0 -1 coregrind/vg_unsafe.h 1.22
M +13 -0 include/vg_kerneliface.h 1.8
--- valgrind/coregrind/vg_syscalls.c #1.58:1.59
@@ -2488,5 +2488,5 @@ PRE(ioctl)
# endif
- case IIOCGETCPS:
+ case VKI_IIOCGETCPS:
/* In early 2.4 kernels, ISDN_MAX_CHANNELS was only defined
* when KERNEL was. I never saw a larger value than 64 though */
@@ -2498,5 +2498,5 @@ PRE(ioctl)
* 2 * sizeof(unsigned long) );
break;
- case IIOCNETGPN:
+ case VKI_IIOCNETGPN:
SYSCALL_TRACK( pre_mem_read, tid, "ioctl(IIOCNETGPN)",
(UInt)&((isdn_net_ioctl_phone *)arg3)->name,
@@ -2887,5 +2887,5 @@ POST(ioctl)
# endif
- case IIOCGETCPS:
+ case VKI_IIOCGETCPS:
/* In early 2.4 kernels, ISDN_MAX_CHANNELS was only defined
* when KERNEL was. I never saw a larger value than 64 though */
@@ -2897,5 +2897,5 @@ POST(ioctl)
* 2 * sizeof(unsigned long) );
break;
- case IIOCNETGPN:
+ case VKI_IIOCNETGPN:
if (res == 0)
VG_TRACK( post_mem_write, arg3, sizeof(isdn_net_ioctl_phone) );
--- valgrind/coregrind/vg_unsafe.h #1.21:1.22
@@ -58,5 +58,4 @@
#include <linux/sem.h> /* for struct sembuf */
-#include <linux/isdn.h> /* for ISDN ioctls */
#include <scsi/sg.h> /* for the SG_* ioctls */
#include <sched.h> /* for struct sched_param */
--- valgrind/include/vg_kerneliface.h #1.7:1.8
@@ -372,4 +372,17 @@ struct vki_ucontext {
#define VKI_ERESTARTSYS 512 /* Restart the syscall */
+/* Copied from linux/isdn.h */
+
+#define VKI_IIOCGETCPS _IO( 'I',21 )
+#define VKI_IIOCNETGPN _IO( 'I',34 )
+
+#define ISDN_MSNLEN 32
+
+typedef struct {
+ char name[ 10 ];
+ char phone[ ISDN_MSNLEN ];
+ int outgoing;
+} isdn_net_ioctl_phone;
+
/* Gawd ... hack ... */
|
|
From: Dirk M. <mu...@kd...> - 2003-11-19 22:07:17
|
CVS commit by mueller:
make it compile on non-C90 compilers. Thanks for the patch.
CCMAIL: 685...@bu...
M +5 -3 vg_symtab2.c 1.59
--- valgrind/coregrind/vg_symtab2.c #1.58:1.59
@@ -673,4 +673,6 @@ void read_symtab( SegInfo* si, Char* tab
Addr sym_addr;
RiSym risym;
+ Char* t0;
+ Char* name;
if (o_strtab == NULL || o_symtab == NULL) {
@@ -785,8 +787,8 @@ void read_symtab( SegInfo* si, Char* tab
/* If we reach here, it's an interesting symbol; record it. */
- Char* t0 = sym->st_name
+ t0 = sym->st_name
? (Char*)(o_strtab+sym->st_name)
: (Char*)"NONAME";
- Char *name = VG_(addStr) ( si, t0, -1 );
+ name = VG_(addStr) ( si, t0, -1 );
vg_assert(name != NULL
/* && 0==VG_(strcmp)(t0,&vg_strtab[nmoff]) */ );
|
|
From: Dirk M. <mu...@kd...> - 2003-11-19 22:02:38
|
CVS commit by mueller:
SHUFPD support
MERGE TO STABLE
CCMAIL: 685...@bu...
M +7 -0 vg_to_ucode.c 1.109
--- valgrind/coregrind/vg_to_ucode.c #1.108:1.109
@@ -3927,4 +3927,11 @@ static Addr disInstr ( UCodeBlock* cb, A
}
+ /* SHUFPD */
+ if (sz == 2 && insn[0] == 0x0F && insn[1] == 0xC6) {
+ eip = dis_SSE3_reg_or_mem_Imm8 ( cb, sorb, eip+2, 16, "shufpd",
+ 0x66, insn[0], insn[1] );
+ goto decode_success;
+ }
+
/* SHUFPS */
if (insn[0] == 0x0F && insn[1] == 0xC6) {
|
|
From: Dirk M. <mu...@kd...> - 2003-11-19 21:50:37
|
CVS commit by mueller:
pkgconfig support. Patch by Dimitri Papadopoulos
MERGE TO STABLE
CCMAIL: 685...@bu...
A valgrind.pc.in 1.1
M +1 -0 .cvsignore 1.5
M +5 -2 Makefile.am 1.58
M +1 -0 configure.in 1.100
--- valgrind/.cvsignore #1.4:1.5
@@ -18,2 +18,3 @@
cachegrind.out.*
autom4te.cache
+valgrind.pc
--- valgrind/Makefile.am #1.57:1.58
@@ -26,5 +26,8 @@
val_DATA = $(SUPP_FILES) default.supp
-BUILT_SOURCES = default.supp
+pkgconfigdir = $(libdir)/pkgconfig
+pkgconfig_DATA = valgrind.pc
+
+BUILT_SOURCES = default.supp valgrind.pc
DISTCLEANFILES = default.supp
@@ -41,5 +44,5 @@
README_KDE3_FOLKS README_PACKAGERS \
README_MISSING_SYSCALL_OR_IOCTL TODO \
- valgrind.spec valgrind.spec.in
+ valgrind.spec valgrind.spec.in valgrind.pc.in
install-exec-hook:
--- valgrind/configure.in #1.99:1.100
@@ -341,4 +341,5 @@
Makefile
valgrind.spec
+ valgrind.pc
docs/Makefile
tests/Makefile
|
|
From: Dirk M. <mu...@kd...> - 2003-11-19 21:33:37
|
CVS commit by mueller: CVS_SILENT ignore M +3 -0 .cvsignore 1.6.2.1 --- valgrind/memcheck/tests/.cvsignore #1.6:1.6.2.1 @@ -49,2 +49,5 @@ *.stdout.out *.stderr.out +metadata +realloc3 +threadederrno |
|
From: Dirk M. <mu...@kd...> - 2003-11-19 21:31:50
|
CVS commit by mueller:
backport compile fix. sorry for the breakage in the stable branch.
M +2 -0 coregrind/vg_syscalls.c 1.40.2.9
M +0 -3 coregrind/vg_unsafe.h 1.14.2.5
M +34 -1 include/vg_kerneliface.h 1.1.2.1
--- valgrind/coregrind/vg_syscalls.c #1.40.2.8:1.40.2.9
@@ -3262,4 +3262,6 @@ void VG_(perform_assumed_nonblocking_sys
MAYBE_PRINTF("statfs64 ( %s, %p )\n", arg1,arg2);
SYSCALL_TRACK( pre_mem_read_asciiz, tid, "statfs64(path)", arg1 );
+ SYSCALL_TRACK( pre_mem_write, tid, "statfs64(buf)",
+ arg2, sizeof(struct statfs64));
KERNEL_DO_SYSCALL(tid,res);
if (!VG_(is_kerror)(res) && res == 0)
--- valgrind/coregrind/vg_unsafe.h #1.14.2.4:1.14.2.5
@@ -84,7 +84,4 @@
#include <sys/types.h>
-#include <asm/statfs.h>
-#undef statfs
-
#include <sys/sysinfo.h>
--- valgrind/include/vg_kerneliface.h #1.1:1.1.2.1
@@ -412,6 +412,39 @@ typedef struct vki_modify_ldt_ldt_s {
+/* statfs structs */
+/*
+ * bits/statfs.h
+ */
-#endif /* ndef __VG_KERNELIFACE_H */
+struct statfs {
+ unsigned int f_type;
+ unsigned int f_bsize;
+ unsigned int f_blocks;
+ unsigned int f_bfree;
+ unsigned int f_bavail;
+ unsigned int f_files;
+ unsigned int f_ffree;
+ int f_fsid[ 2 ];
+ unsigned int f_namelen;
+ unsigned int f_frsize;
+ unsigned int f_spare[5];
+};
+
+struct statfs64 {
+ unsigned int f_type;
+ unsigned int f_bsize;
+ unsigned long long f_blocks;
+ unsigned long long f_bfree;
+ unsigned long long f_bavail;
+ unsigned long long f_files;
+ unsigned long long f_ffree;
+ int f_fsid[ 2 ];
+ unsigned int f_namelen;
+ unsigned int f_frsize;
+ unsigned int f_spare[5];
+};
+
+
+#endif /* __VG_KERNELIFACE_H */
/*--------------------------------------------------------------------*/
|
|
From: Dirk M. <dm...@gm...> - 2003-11-19 20:20:10
|
On Wednesday 19 November 2003 21:07, Nicholas Nethercote wrote: > Much better, I find --assume-2.4 confusing. Or, to be consistent with > --workaround-gcc296-bugs, --workaround-suse81-bugs (or whatever the > version is)? I agree, but can we first investigate if this is really a bug in the SuSE kernel? If I'd have a test app I could pass it to the kernel developers or verify it against the spec. I might try building one myself, just in case somebody has already done this work.. |
|
From: Nicholas N. <nj...@ca...> - 2003-11-19 20:11:41
|
CVS commit by nethercote: Fix regtest for change of error message. M +0 -1 dlclose.stderr.exp 1.5 --- valgrind/cachegrind/tests/dlclose.stderr.exp #1.4:1.5 @@ -1,4 +1,3 @@ -discard syms in /.../tests/myprint.so due to munmap() I refs: |
|
From: Nicholas N. <nj...@ca...> - 2003-11-19 20:10:41
|
On Wed, 19 Nov 2003, Dirk Mueller wrote: > trying to fix compilation. Does it work now for everybody? yep, thanks. I just fixed cachegrind/tests/dlclose, which had broken due to the "discard" message no longer being shown. N |
|
From: Nicholas N. <nj...@ca...> - 2003-11-19 20:07:06
|
On Wed, 19 Nov 2003, Jeremy Fitzhardinge wrote: > Perhaps I should rename the option to --broken-suse-kernel=yes. Much better, I find --assume-2.4 confusing. Or, to be consistent with --workaround-gcc296-bugs, --workaround-suse81-bugs (or whatever the version is)? N |
|
From: Jeremy F. <je...@go...> - 2003-11-19 18:44:45
|
On Wed, 2003-11-19 at 09:47, Dirk Mueller wrote: > On Wednesday 19 November 2003 18:44, Jeremy Fitzhardinge wrote: > > > The intent is that the valgrind wrapper script use --assume-2.4=yes when > > it detects a SuSE kernel - I hadn't got around to it. Perhaps I should > > rename the option to --broken-suse-kernel=yes. > > Maybe you can elaborate in more detail what is broken? V does a feature test to see if its running on a 2.6-like kernel, which is what it would prefer. SuSE passes those feature tests because they've extended their 2.4 kernel to include the new NPTL syscalls (like RH). Unfortunately they seem subtly broken, and even though the syscalls works and take the new args, they behave differently. The message you posted suggests that at least one proxy LWP just evaporated without notifying anyone of its death. On standard 2.4 kernels and RH 2.4 kernels it works OK without --assume-2.4=yes - it really is just for SuSE kernels (and perhaps other vendors with hacked up 2.4 kernels). J |
|
From: Dirk M. <mu...@kd...> - 2003-11-19 17:47:44
|
On Wednesday 19 November 2003 18:44, Jeremy Fitzhardinge wrote: > The intent is that the valgrind wrapper script use --assume-2.4=yes when > it detects a SuSE kernel - I hadn't got around to it. Perhaps I should > rename the option to --broken-suse-kernel=yes. Maybe you can elaborate in more detail what is broken? |
|
From: Jeremy F. <je...@go...> - 2003-11-19 17:44:47
|
On Wed, 2003-11-19 at 09:11, Dirk Mueller wrote: > It works when I use --assume-2.4=yes, but I don't consider this switch to be a > good idea. can't we detect whatever weird kernel feature we now need at > runtime? The intent is that the valgrind wrapper script use --assume-2.4=yes when it detects a SuSE kernel - I hadn't got around to it. Perhaps I should rename the option to --broken-suse-kernel=yes. J |
|
From: Dirk M. <mu...@kd...> - 2003-11-19 17:11:39
|
On Wednesday 19 November 2003 16:18, Nicholas Nethercote wrote: > What's the problem with HEAD -- it doesn't work on your machine at all? > Have you told Jeremy? (well, I guess he knows now...) This happens: ==25531== Memcheck, a memory error detector for x86-linux. ==25531== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==25531== Using valgrind-HEAD, a program supervision framework for x86-linux. ==25531== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==25531== Estimated CPU clock rate is 1540 MHz ==25531== For more details, rerun with: -v ==25531== ==25531== ==25531== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==25531== malloc/free: in use at exit: 0 bytes in 0 blocks. ==25531== malloc/free: 103 allocs, 103 frees, 7925 bytes allocated. ==25531== For a detailed leak analysis, rerun with: --leak-check=yes ==25531== For counts of detected errors, rerun with: -v --25531-- TID 1: proxy LWP 0 exited with status 0 valgrind: vg_proxylwp.c:1360 (vgPlain_proxy_sanity): Assertion `sane' failed. ==25531== at 0x4017A01E: vgPlain_skin_assert_fail (vg_mylibc.c:1102) ==25531== by 0x4017A01D: assert_fail (vg_mylibc.c:1098) ==25531== by 0x4017A0A8: vgPlain_core_assert_fail (vg_mylibc.c:1109) ==25531== by 0x4017E89B: vgPlain_proxy_sanity (vg_proxylwp.c:1360) ==25531== by 0x40175060: vgPlain_do_sanity_checks (vg_main.c:2051) ==25531== by 0x4017484A: vgPlain_main (vg_main.c:1699) sched status: Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==25531== at 0x40171A33: vgPlain___libc_freeres_wrapper (vg_intercept.c:177) ==25531== by 0x40271057: __GI_exit (in /lib/i686/libc.so.6) ==25531== by 0x8048A9D: (within /bin/true) ==25531== by 0x4025AD16: __libc_start_main (in /lib/i686/libc.so.6) ==25531== by 0x80488C0: (within /bin/true) Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: js...@ac... In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. It works when I use --assume-2.4=yes, but I don't consider this switch to be a good idea. can't we detect whatever weird kernel feature we now need at runtime? |
|
From: Dirk M. <mu...@kd...> - 2003-11-19 17:01:28
|
CVS commit by mueller:
add CVTPD2PS support, based on patch by Josef Weidendorfer
MERGE TO STABLE
M +8 -0 vg_to_ucode.c 1.108
--- valgrind/coregrind/vg_to_ucode.c #1.107:1.108
@@ -4761,4 +4761,12 @@ static Addr disInstr ( UCodeBlock* cb, A
}
+ /* CVTPD2PS -- convert two doubles to two floats. */
+ if (sz == 2 &&
+ insn[0] == 0x0F && insn[1] == 0x5A) {
+ eip = dis_SSE3_reg_or_mem ( cb, sorb, eip+2, 16, "cvtpd2ps",
+ 0x66, insn[0], insn[1] );
+ goto decode_success;
+ }
+
/* SQRTPD: square root of packed double. */
if (sz == 2
|
|
From: Dirk M. <dm...@gm...> - 2003-11-19 17:00:41
|
Hi, Hmm, any idea how to tackle this problem? |
|
From: Dirk M. <mu...@kd...> - 2003-11-19 16:55:29
|
CVS commit by mueller:
trying to fix compilation. Does it work now for everybody?
M +0 -3 coregrind/vg_unsafe.h 1.21
M +34 -1 include/vg_kerneliface.h 1.7
--- valgrind/coregrind/vg_unsafe.h #1.20:1.21
@@ -91,7 +91,4 @@
#include <sys/types.h>
-#include <asm/statfs.h>
-#undef statfs
-
#include <sys/sysinfo.h>
--- valgrind/include/vg_kerneliface.h #1.6:1.7
@@ -672,6 +672,39 @@ struct vki_sockaddr {
};
+/* statfs structs */
+/*
+ * bits/statfs.h
+ */
-#endif /* ndef __VG_KERNELIFACE_H */
+struct statfs {
+ unsigned int f_type;
+ unsigned int f_bsize;
+ unsigned int f_blocks;
+ unsigned int f_bfree;
+ unsigned int f_bavail;
+ unsigned int f_files;
+ unsigned int f_ffree;
+ int f_fsid[ 2 ];
+ unsigned int f_namelen;
+ unsigned int f_frsize;
+ unsigned int f_spare[5];
+};
+
+struct statfs64 {
+ unsigned int f_type;
+ unsigned int f_bsize;
+ unsigned long long f_blocks;
+ unsigned long long f_bfree;
+ unsigned long long f_bavail;
+ unsigned long long f_files;
+ unsigned long long f_ffree;
+ int f_fsid[ 2 ];
+ unsigned int f_namelen;
+ unsigned int f_frsize;
+ unsigned int f_spare[5];
+};
+
+
+#endif /* __VG_KERNELIFACE_H */
/*--------------------------------------------------------------------*/
|
|
From: Nicholas N. <nj...@ca...> - 2003-11-19 15:18:10
|
On Wed, 19 Nov 2003, Dirk Mueller wrote: > Ok, same question to you: where is statfs64 defined for you? for me its in > asm/statfs.h bits/statfs.h > Its a bit tricky to use this here since normally you're supposed to do this > via the D_FILE_OFFSET_BITS define, which we can't do since we want the old > 32bit version and the 64bit version. > > somehow we need a script that calculates the magic values of sizeof() etc and > then just import that header file with the list of #define's . Including > nonstandard kernel headers is just too unportable, even for valgrind. > > > > Also, not printing the "discarding..." message will, I think, break some > > regression tests. These problems may also apply to the stable branch. > > Well, make regtest prints 0 failures for me. do you see some? where? Sorry, my mistake. > Of course I did that. 0 failures in branch, all failed in HEAD, but thats > because HEAD does not even work on /bin/true for me. Sorry for the mis-accusation. What's the problem with HEAD -- it doesn't work on your machine at all? Have you told Jeremy? (well, I guess he knows now...) N |
|
From: Dirk M. <mu...@kd...> - 2003-11-19 10:34:12
|
On Wednesday 19 November 2003 10:59, Nicholas Nethercote wrote: > > implement statfs64, utimes and clock_gettime > vg_syscalls.c: In function `before_statfs64': > vg_syscalls.c:4070: sizeof applied to an incomplete type Ok, same question to you: where is statfs64 defined for you? for me its in asm/statfs.h Its a bit tricky to use this here since normally you're supposed to do this via the D_FILE_OFFSET_BITS define, which we can't do since we want the old 32bit version and the 64bit version. somehow we need a script that calculates the magic values of sizeof() etc and then just import that header file with the list of #define's . Including nonstandard kernel headers is just too unportable, even for valgrind. > > Also, not printing the "discarding..." message will, I think, break some > regression tests. These problems may also apply to the stable branch. Well, make regtest prints 0 failures for me. do you see some? where? > Can you fix them? Thanks. And don't forget to run the regression tests > before committing :) Of course I did that. 0 failures in branch, all failed in HEAD, but thats because HEAD does not even work on /bin/true for me. |
|
From: Nicholas N. <nj...@ca...> - 2003-11-19 09:59:30
|
On Wed, 19 Nov 2003, Dirk Mueller wrote: > CVS commit by mueller: > > implement statfs64, utimes and clock_gettime The HEAD now doesn't compile on my machine: vg_syscalls.c: In function `before_statfs64': vg_syscalls.c:4070: sizeof applied to an incomplete type vg_syscalls.c: In function `after_statfs64': vg_syscalls.c:4075: sizeof applied to an incomplete type Also, not printing the "discarding..." message will, I think, break some regression tests. These problems may also apply to the stable branch. Can you fix them? Thanks. And don't forget to run the regression tests before committing :) N |
|
From: Dirk M. <mu...@kd...> - 2003-11-19 08:57:21
|
CVS commit by mueller:
make use of statfs64 and make code blocks adjacent
M +6 -6 vg_syscalls.c 1.58
--- valgrind/coregrind/vg_syscalls.c #1.57:1.58
@@ -4057,4 +4057,9 @@ PRE(statfs)
}
+POST(statfs)
+{
+ VG_TRACK( post_mem_write, arg2, sizeof(struct statfs) );
+}
+
PRE(statfs64)
{
@@ -4063,10 +4068,5 @@ PRE(statfs64)
SYSCALL_TRACK( pre_mem_read_asciiz, tid, "statfs64(path)", arg1 );
SYSCALL_TRACK( pre_mem_write, tid, "statfs64(buf)",
- arg2, sizeof(struct statfs) );
-}
-
-POST(statfs)
-{
- VG_TRACK( post_mem_write, arg2, sizeof(struct statfs) );
+ arg2, sizeof(struct statfs64) );
}
|
|
From: Jeremy F. <je...@go...> - 2003-11-19 04:28:52
|
OK, I've had even more of a look into what's happening here. The quick
answer is that is can probably be done without too much nastiness,
though our libpthread will need to know some of glibc's secret
knowledge.
The key thing is that %gs points to a thing called tcbhead_t, which
contains pointers to the rest of the thread-specific data structures.
pthread_create doesn't really do much with this except init it;
___tls_get_addr does all the hard work of on-demand copying, which we
don't care about.
Aside from the shape of tcbhead_t (which is simple), libpthread doesn't
need to know much about how it works - it ends up calling _dl_* internal
functions to manipulate it, and to find out other info it needs to know
(like how big the static per-thread info is, which it needs to build
into the thread stack).
Our libpthread can call those same functions, and thereby do the same
thing.
For reference, they appear to be:
_dl_get_tls_static_info(size_t *size, size_t *alignment)
Get the size and alignment of the per-thread variable space we
need to stick on the stack under tcbhead_t.
_dl_allocate_tls_init(void *mem)
(Re)Initialize the TLS info at mem. mem points to the
tcbhead_t.
_dl_allocate_tls(void *mem)
Do the initial initialization of the TCB (ie, allocate the DTV).
_dl_deallocate_tls(void *mem, bool free_tcb)
Deallocate memory.
tcbhead_t is:
typedef struct
{
void *tcb; /* Pointer to the TCB. Not necessary the
thread descriptor used by libpthread. */
dtv_t *dtv;
void *self; /* Pointer to the thread descriptor. */
int multiple_threads;
uintptr_t sysinfo;
} tcbhead_t;
We don't care about dtv_t, since the dynamic linker will do all the work
to maintain it.
The other part is implementing the TLS "kernel" support, which is easy.
So in all, this only looks like a few day's work (maybe less).
J
|
|
From: Dirk M. <mu...@kd...> - 2003-11-19 00:58:29
|
CVS commit by mueller:
be more silent by default
M +4 -3 vg_symtab2.c 1.48.2.3
--- valgrind/coregrind/vg_symtab2.c #1.48.2.2:1.48.2.3
@@ -2300,4 +2300,5 @@ void VG_(unload_symbols) ( Addr start, U
return;
+ if (VG_(clo_verbosity) > 0)
VG_(message)(Vg_UserMsg,
"discard syms in %s due to munmap()",
|