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: Nicholas N. <nj...@ca...> - 2004-08-20 14:08:43
|
On Fri, 20 Aug 2004, Paul Mackerras wrote: > I'm a long way from being an automake guru. :-P We all are... :( >> Also, I don't like the use of #ifdefs within the Makefile.am files. >> Dealing with different platforms via #ifdefs leads to night-sweats, >> feeble-mindedness and delirium. > > I looked at the automake manual and that was the only obvious way to > do it (well the only way that was obvious to me :), but as I said, I > know little about automake. Is anyone on the list an automake expert? > (I much prefer the kernel's way of dealing with multiple platforms, > actually.) What is the kernel's way of dealing with it -- I thought it was with symlinks, which is what I suggested in my dir/file proposal. Does Valgrind differ in some way from the kernel in this respect? N |
|
From: Nicholas N. <nj...@ca...> - 2004-08-20 13:22:04
|
On Fri, 20 Aug 2004, Paul Mackerras wrote: >> 2. Therefore we should get rid of vg_unsafe.h, and instead put our own >> versions of the kernel types (prefixed with "vki_") in vg_kerneliface.h. > > We will still be doing some glibc calls, won't we, though? Yes. Eg. stage1.c and ume.c use glibc functions, as does vg_main.c. But for the syscall wrappers, and when we call syscalls directly in vg_mylibc.c, we're dealing directly with the kernel. >> 4. Recent versions of the Linux source (eg. 2.6.3 doesn't have it, 2.6.7 >> does have it) have a file include/linux/syscalls.h with a big list of >> syscall prototypes, eg: >> >> asmlinkage long sys_open(const char __user *filename, >> int flags, int mode); > > That is a list of prototypes of the internal functions that implement > the various system calls. It looks like all system calls get vectored > directly to the corresponding sys_blah() routine on x86 (except for a > few that call old_blah() routines), but that is not true on other > platforms; for example on ppc we intercept a few by vectoring them to > a ppc_blah() function which then generally calls sys_blah(). Ok. I'm interested in the general case for all architectures. Basically I want to know which Linux syscall wrappers can be handled with the same code on all architectures, ie. go in common-linux/ (or whatever it gets called), and which syscall wrappers must go in x86-linux/ or ppc-linux/ or wherever. I'm hoping that most can go in common-linux/ to reduce the amount of code. > The prototype would generally be the same though. Only generally the same? Since syscalls are the main way that user programs interact with the kernel, I would expect that there is, somewhere, a way of determining exactly what the interface between them is. I was hoping include/linux/syscalls.h might have served as that official interface, but it seems like this is not quite the case? If not, how/where is this interface officially defined? Is it just implicitly scattered throughout the kernel? > Select isn't entirely generic, x86 passes the args in a block in > memory but ppc passes them in the normal fashion. Is there a way of knowing which syscalls are entirely generic and which ones have arch-specific aspects? > I have a bunch of changes that I would like to see go in that start > abstracting things so that PPC will fit in. The first change is to > move the machine-dependent fields of ThreadState into a single `arch' > member whose type is defined in an arch-dependent header. I'll send a > patch out shortly. Yes, it makes sense to get the directory structure right first, as discussed in my reply to your patch message. N |
|
From: Paul M. <pa...@sa...> - 2004-08-20 13:18:29
|
Nicholas Nethercote writes: > First thing: I applied the patch fine, but had automake troubles building > it. Automake output is attached. Any idea what is the problem? Perhaps > it would be easier to put the whole tarball up? Just to answer this bit quickly: I have been using aclocal-1.7 and automake-1.7, because I had problems with earlier versions. I'm a long way from being an automake guru. :-P > Also, I don't like the use of #ifdefs within the Makefile.am files. > Dealing with different platforms via #ifdefs leads to night-sweats, > feeble-mindedness and delirium. I looked at the automake manual and that was the only obvious way to do it (well the only way that was obvious to me :), but as I said, I know little about automake. Is anyone on the list an automake expert? (I much prefer the kernel's way of dealing with multiple platforms, actually.) Paul. |
|
From: Nicholas N. <nj...@ca...> - 2004-08-20 11:47:31
|
On Fri, 20 Aug 2004, Paul Mackerras wrote:
> I have a patch that starts the work of abstracting out the
> architecture-specific parts of Valgrind into their own files, in order
> to enable them to be replaced on other architectures (e.g. PowerPC :).
Good stuff.
I am extremely sympathetic to the reasoning behind this patch; having
been looking at the x86-64 port, I see how necessary the restructuring is.
Once it's in, assuming it's done well, it will make working on ports much
easier, because you're much less likely to have clashes. And on the
whole, at first look the patch looks to me, overall, very much on the
right track.
First thing: I applied the patch fine, but had automake troubles building
it. Automake output is attached. Any idea what is the problem? Perhaps
it would be easier to put the whole tarball up?
I have lots of comments, but I'll put the important things, which everyone
should read, first. This stuff is IMPORTANT, and should be read by anyone
at all interested in the various Valgrind ports.
First is about commit philosophy. For changes like this, is it better to
slip these things in gradually, or do it all in one big hit? I prefer the
former; in fact I've already started doing it for Opteron a bit (eg. my
committting of the 64-bit clean version of the allocator). I like this
because it's easier to catch mistakes when using small steps, and the code
tends to get scrutinised more. Anyone disagree?
Related to this; development is proceeding (and will continue to proceed
AFAICT) at such a rate that we're in danger of never putting out any
stable releases, which is bad. We keep getting bug reports for bugs in
2.0.0 that are fixed in 2.1.X, which shows people are still using 2.0.0.
Second and more important thing is that I think it is *crucial* that we
get the file/directory structure right, at the start, since this is
difficult to change once it's in place; and this is something that should
be done in one hit. The contents of the actual files aren't so hard to
change, and so can be done bit by bit.
There are two aspects to this -- the directory structure, and then the
interface between the generic bits and the platform-specific bits. And by
interface, I don't mean at the level of functions and variables, rather at
the level of files, ie. which header files get included from
platform-specific-land into generic-land, and how the platform-specific
code is compiled and linked with generic code.
For example, Paul has used coregrind/arch/x86-common/vg_archdefs.h, which
contains things like the arch-specific part of the ThreadState, which all
$ARCH-common directories will require. But it also contains various
things that I think will only be used within the x86-specific code, and so
the core doesn't need to see.
Also, I don't like the use of #ifdefs within the Makefile.am files.
Dealing with different platforms via #ifdefs leads to night-sweats,
feeble-mindedness and delirium.
So, we need to thrash this out a bit. To start the discussion, here's a
proposal, which shares some features of Paul's patch, but also has some
important differences.
----
Nick's 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 (aka common-common)
2a. some arch-specific, OS-independent code (aka $ARCH-common)
2b. some arch-independent, OS-specific code (aka common-$OS)
3. some platform-specific code (aka $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:
valgrind/
coregrind/
arch/
arch_common_defs.h (contains arch-specific definitions)
common_os_defs.h (contains OS-specific definitions)
arch_os_defs.h (contains platform-specific definitions)
arch_common@ (symlink to $ARCH-common/, made at config-time)
common_os@ (symlink to common-$OS/, made at config-time)
arch_os@ (symlink to $ARCH-$OS/, made at config-time)
$ARCH-common/
arch_common_macros.h (contains arch-specific macros used by core)
arch_common.a (contains all arch-specific code)
common-$OS/
common_os_macros.h (contains OS-specific macros used by core)
common_os.a (contains all OS-specific code)
$ARCH-$OS/
arch_os_macros.h (contains platform-specific macros used by core)
arch_os.a (contains all platform-specific code)
$ARCH and $OS would, of course, be replaced with real arch and OS names,
eg. x86-linux.
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.
The generic part would need only these six #includes:
#include "platform/arch_common_defs.h"
#include "platform/common_os_defs.h"
#include "platform/arch_os_defs.h"
These could be put in vg_include.h and thus be made visible to all core
code. Or not.
Each of the _defs.h files would have the following respective #includes:
#include "platform/arch_common/arch_common_macros.h"
#include "platform/common_os/common_os_macros.h"
#include "platform/arch_os/arch_os_macros.h"
in order to pull in the relevant _macros.h files -- the symlinks would
ensure the right ones are pulled in.
When building stage2, coregrind/Makefile.am would just link all the core
modules with:
- platform/arch_common/arch_common.a
- platform/common_os/common_os.a
- platform/arch_os/arch_os.a
The symlinks would again ensure this works. These .a files would be made
by linking together all the .o files in each part.
Each non-generic sub-dir can also include as many other .c, .h and .S
files as it needs (plus anything else, like ld scripts). But the generic
part wouldn't see or care about that.
Note that arch/ is a really bad name. I'm not convinced we even need that
subdirectory between coregrind/ and the non-generic subdirs -- it will
just create more typing, for little benefit.
I haven't considered skins at all here. Perhaps each of the the proposed
headers needs to be split into two halves: one for the skin-visible
stuff, and one for the core-visible stuff (which would #include the
skin-visible header).
I haven't considered asm code at all here; some .S files need some
definitions, but you can't have any macros included in .S files.
(Note for the above two paragraphs: this skin/non-skin and asm/non-asm
header split is why we currently have four main headers: vg_include.h,
vg_skin.h, vg_constants.h and vg_constants_skin.h.)
I haven't considered the UME stuff that is shared between stage1 and
stage2. Not sure about that, it would probably be kept separate at least
to some extent.
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.
The names might be a bit confusing, in particular I'm not sure about the
wisdom of reusing "common" in the names "arch-common" and "common-os".
Perhaps the following would be clearer (it would also be less typing):
- arch-common --> arch
- common-os --> os
- arch-os --> arch-os
Eg. x86/, ppc/, x86-linux/, linux/, instead of x86-common/, ppc-common/,
x86/linux, common-linux.
I haven't used the "vg_" prefix in filenames above -- it's not necessary
just creates more typing, and the more recently added files don't use it.
Does that make sense? It feels very idealistic, but then, it feels very
clean and generic too, and I can't see a better way to do it. The nice
thing is that although the actual code/definitions/macros might get moved
around between the four parts over time, I believe the file/dir structure,
#include technique, and build technique would not need to change.
My preference would be to create this structure (or whatever we decide on)
in one hit, and then start moving things around, ie. commit the contents
of Paul's patch small steps at a time.
Comments are welcome!
----
Ok, now for various lower-level comments about the patch, mostly aimed at
Paul.
- Have you tried fitting your PPC port into this structure? Does it fit?
That's a good test.
- You haven't touched the x86/ directory, I see. Any reason why not?
- The syscalls are going to need a whole lot more abstraction/factoring
than what you've done with mmap(), but as you said the patch is only a
start.
- You've used VG_(arch_...) for a lot of names. I think a new prefix, eg.
VGA_(...) would be good. We could even use different prefixes for
definitions in the arch-common, common-os and arch-os interface, and then
a different prefix for code within those non-generic parts that isn't seen
by the generic code. Or maybe that's going too far, but something like
that would be good.
- VG_(arch_deliver_signal)() is big -- is it possible to factor out the
generic/non-generic parts better?
- --pointer-check is not necessarily x86-specific. The current mechanism
(using segments) is x86-specific, but it could also be done with eg.
explicit pointer-masking.
- why are arch_set_arg_and_ret() and arch_thread_initial_stack() not
VG_() prefixed?
- There doesn't seem to be much consistency in the file-naming scheme, eg.
some have "arch" in them, some have "x86", some don't. My proposal above
partly addresses this.
- I'm not happy about vg_libpthread.c being in x86-$OS/ subdirs -- huge
parts will be shared with the x86-freebsd, etc. But maybe you copied that
from the current (misleading) coregrind/arch/x86-$OS/ directories, the
contents of which aren't actually used.
- If this patch was done in small steps, is there any order you'd
prefer/suggest?
- It would be great to know if this matches well with Doug's FreeBSD port.
That's probably enough from me for the moment :)
N |
|
From: Tom H. <th...@cy...> - 2004-08-20 03:14:40
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-08-20 03:00:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow errs1: valgrind -q ./errs1 execve: valgrind -q ./execve execve2: valgrind -q --trace-children=yes ./execve2 exitprog: valgrind -q ./exitprog fpeflags: valgrind -q ./fpeflags fprw: valgrind -q ./fprw fwrite: valgrind -q ./fwrite inits: valgrind -q ./inits inline: valgrind -q ./inline insn_basic: valgrind -q ./../../none/tests/insn_basic insn_cmov: valgrind -q ./../../none/tests/insn_cmov insn_fpu: valgrind -q ./../../none/tests/insn_fpu insn_mmx: valgrind -q ./../../none/tests/insn_mmx insn_mmxext: valgrind -q ./../../none/tests/insn_mmxext insn_sse: valgrind -q ./../../none/tests/insn_sse malloc1: valgrind -q ./malloc1 malloc2: valgrind -q ./malloc2 malloc3: valgrind -q ./malloc3 Could not read `malloc3.stderr.exp' make: *** [regtest] Error 2 |
|
From: <js...@ac...> - 2004-08-20 02:55:36
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2004-08-20 03:50:00 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow sem: valgrind ./sem semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 173 tests, 4 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_fcntl (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2004-08-20 02:39:36
|
Nightly build on dunsmere ( Fedora Core 2 ) started at 2004-08-20 03:20:01 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 178 tests, 8 stderr failures, 1 stdout failure ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_socketpair (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/writev (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-08-20 02:19:48
|
Nightly build on audi ( Red Hat 9 ) started at 2004-08-20 03:15:02 BST 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 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 178 tests, 8 stderr failures, 0 stdout failures ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_socketpair (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-08-20 02:13:17
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-08-20 03:10:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow seg_override: valgrind ./seg_override sem: valgrind ./sem semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 178 tests, 3 stderr failures, 0 stdout failures ================= helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-08-20 02:08:23
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-08-20 03:05:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 178 tests, 9 stderr failures, 1 stdout failure ================= addrcheck/tests/toobig-allocs (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/badjump (stderr) memcheck/tests/brk (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/new_nothrow (stderr) memcheck/tests/toobig-allocs (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Paul M. <pa...@sa...> - 2004-08-20 01:10:10
|
Nicholas Nethercote writes: > Here's what I understand to be correct: > > 1. Many glibc and kernel types differ. For the syscall wrappers in > vg_syscalls.c, and for the syscalls called directly from various functions > in vg_mylibc.c, we need to use the kernel types. When using glibc > functions (eg. in ume.c) we need to use the glibc ones. Yes. > [Nb: why do glibc and the kernel have different types? Is this so glibc > can have more control, and change the types if it wants?] It's partly for backwards compatibility, I think, and maybe partly for POSIX compliance. Once a difference arises, it tends to persist. Also, the glibc people decided that they needed 64-bit dev_t but Linus vetoed that for the kernel as being just to enormously greater than what was actually needed. > 2. Therefore we should get rid of vg_unsafe.h, and instead put our own > versions of the kernel types (prefixed with "vki_") in vg_kerneliface.h. We will still be doing some glibc calls, won't we, though? > 4. Recent versions of the Linux source (eg. 2.6.3 doesn't have it, 2.6.7 > does have it) have a file include/linux/syscalls.h with a big list of > syscall prototypes, eg: > > asmlinkage long sys_open(const char __user *filename, > int flags, int mode); > > Note that this is different to the glibc open(), which returns an 'int'. > > Does anyone know about this? It seems pretty definitive. Most syscalls That is a list of prototypes of the internal functions that implement the various system calls. It looks like all system calls get vectored directly to the corresponding sys_blah() routine on x86 (except for a few that call old_blah() routines), but that is not true on other platforms; for example on ppc we intercept a few by vectoring them to a ppc_blah() function which then generally calls sys_blah(). The prototype would generally be the same though. > However, despite the seeming genericity, some of those pass arguments in > strange ways -- eg. select() on i386 uses the strange args-in-memory-block > method. On x86, the select system call invokes old_select(), which copies in the arguments and calls sys_select(). > Then include/asm/unistd.h seems to have all the arch-specific ones, eg: > > asm-i386/unistd.h: > asmlinkage int sys_clone(struct pt_regs regs); Note that the regs are passed by value! The regs parameter here is just the exception frame established by the system call entry, not anything the user program has to provide. > Also, I think we should: > - have generic wrappers for the generic syscalls (eg. open()) > - have per-arch wrappers for the non-generic syscalls (eg. clone()) > - not sure about the generic-but-weird ones (eg. select()) Select isn't entirely generic, x86 passes the args in a block in memory but ppc passes them in the normal fashion. > I'm happy to do (2) and (3) above now, if people agree they're the right > thing to do. I will do (4) when working on the Opteron port if that is > the right thing. Please let me know if I've got anything wrong, or am > missing anything important. I have a bunch of changes that I would like to see go in that start abstracting things so that PPC will fit in. The first change is to move the machine-dependent fields of ThreadState into a single `arch' member whose type is defined in an arch-dependent header. I'll send a patch out shortly. Paul. |
|
From: Paul M. <pa...@sa...> - 2004-08-20 01:10:09
|
I have a patch that starts the work of abstracting out the architecture-specific parts of Valgrind into their own files, in order to enable them to be replaced on other architectures (e.g. PowerPC :). The patch is at: http://ozlabs.org/~paulus/val-abstraction-040820.patch.gz The patch is against current CVS. I haven't included it inline since it is large (~56k compressed), but I would be happy to email to anyone on request. The major change introduced by the patch is to replace all the architecture-specific members of ThreadState with an `arch' member, whose type is defined in an arch-specific header. It also moves the handling of those fields into functions in an arch-specific source file. The patch doesn't add any support for other architectures. I have added a coregrind/arch/x86-common directory. I have not moved existing files in this patch except for moving vg_unistd.h into coregrind/arch/x86-linux. There are quite a few files in coregrind that would be candidates for moving into x86-linux or x86-common later. I would really appreciate it if some people could review the patch fairly soon. I know it's a large patch, but people keep making changes in CVS and therefore the patch will bitrot moderately quickly. This patch is a start but there is still more that needs to be abstracted, particularly in vg_translate.c. If this patch could be applied to CVS it will make subsequent patches easier. With this patch, Valgrind compiles and runs on x86 (on my P4 running Debian sid and a 2.6 kernel) and passes exactly the same set of tests as current CVS does. Paul. |