You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
(17) |
2
(15) |
3
(36) |
4
(24) |
5
(36) |
|
6
(18) |
7
(16) |
8
(18) |
9
(19) |
10
(18) |
11
(37) |
12
(18) |
|
13
(13) |
14
(21) |
15
(27) |
16
(10) |
17
(16) |
18
(25) |
19
(21) |
|
20
(11) |
21
(14) |
22
(6) |
23
(15) |
24
(27) |
25
(3) |
26
(9) |
|
27
(16) |
28
(24) |
29
(21) |
30
(43) |
31
(42) |
|
|
|
From: Jeremy F. <je...@go...> - 2005-03-31 21:26:57
|
Nicholas Nethercote wrote:
> 2. Copy a libc into Valgrind, eg. uClibc.
>
> Pros: as for (1)
> Cons: lots of extra code, much of it unused
Well, the nice thing about uClibc is that its very configurable, and its
easy to drop stuff you don't need.
> AIUI, Julian favours (3), Jeremy favours either (1) or (2). I'm
> leaning towards (3).
>
> I've undoubtedly oversimplified the issues involved and missed out
> some important details. Anyone care to add their two cents? I figure
> it's a good idea to discuss this and come to some sort of
> conclusion/agreement before too much implementation effort occurs.
I definitely understand the appeal of 3, and I don't object too strongly
if we go that way, but I think we should really avoid wasting effort.
Every line of code is a liability, and if we're going to maintain code,
it had better pay for itself.
It seems to me there are four classes of functions:
1. very simple utility functions, like str* & mem*, atoX, etc
2. portable but complex things, like formatted string handling (*printf)
3. allocation
4. kernel/syscall stuff
I also see there are two distinct implementation decisions:
1. whether we use standard APIs for these various functions
2. whether we use our own implementation or someone else's (which can
either mean using the system's installed library, or including
another implementation within the Valgrind source).
(Naturally deciding to use someone else's implementation in 2 tends to
strongly suggest we'll use a standard API.)
The decision about what implementation to use can be made independently
for each class of library function:
1. simple utilities
1. Our implementations are functionally identical to their libc
counterparts (or should be if they're not). There are no
problems with the libc API for our purposes, so we should
just use it as is. This means dropping the VG_() prefix and
using standard function names.
2. There's no benefit to having our own implementations. On
the other hand, they already exist, and they're easy to
maintain.
2. formatting
1. Our formatting APIs are very similar to the standard ones;
we probably don't win much by using different names.
2. In many ways, our private implementations of formatting are
pretty limited compared to the standard onces; for example
there's no snprintf (only sprintf), which leads to a rare
but persistent series of buffer-overrun bugs; a limited
implementation of the standard formatting characters; and
clunky ways of doing IO (all the character-at-a-time
unbuffered IO is a bit of an eyesore). On the other hand,
we have some useful extra formats, like %y for symbolic
expansion of an address.
3. allocation
1. Our allocation model is basically the same as libc's, with
the added complexity of arenas. We're really only using the
arenas as a crude kind of memory profiling mechanism, with
sort-of typing (since you need to know the arena a pointer
came from to be able to free it). I'm not sure we get much
value from the arena stuff; if we dropped it, we would have
an exact analogue of malloc/free (which is what the tools
use anyway).
2. We'll always need to control memory use carefully, so we
need to either control the malloc/free layer, or the
underlying low-level allocator (ie, if we used a libc
malloc/free, but controlled where it gets its memory from).
4. syscall interfaces
1. There are two kinds of syscall we make: those which are on
behalf of the client, and those we need for ourselves. The
former are almost entirely done in one place
(VGA_(client_syscall)), with a couple exceptions; we care a
lot about exactly how these are implemented. The latter, we
don't care too much, so long as they interact well with the
client's uses. I guess this is a bit of a wash.
2. The syscall interface is going to be the hardest of these
three to port; it could well be a major issue for some
operating systems which don't document that layer at all;
using the native libraries would be a huge boon. The main
API problem with using libc is the global nature of errno;
there are various ways of fixing this by making it
thread-local data, but this gets messy and thread-library
specific.
Hm, so I guess what I'm thinking is:
* That that while it is a waste of effort to implement our own libc,
the libc API isn't very good for us. We've got masses of buffer
overrun and other bugs lurking in there, and the libc APIs make it
very difficult to avoid them. We should have our own libraries
for things like formatting, but they should only be vaguely
modelled on libc's formatting library. Any use of str* should be
viewed with suspicion; a better string structure would go a long
way to help.
* I'd like to open the discussion about dropping arena_* functions,
and just using a plain malloc/free-like interface for all
allocation. I don't see us getting much benefit from them, and
they add a low level of pervasive complexity all over the place
(for example, any function which allocates memory on behalf of
anyone else needs to take an extra arena argument).
* I guess its hard to avoid having our own syscall interface
implementation, though I really don't like the name of "kal".
There should be *no* abstraction in there; it needs to be an
exceedingly thin layer. How about "kil"?
J
|
|
From: Jeremy F. <je...@go...> - 2005-03-31 21:25:41
|
Julian Seward wrote:
>This strikes me as a bit like the kernel-headers issue. Although 1 and
>2 are attractive from the amount-of-work point of view, the only sane way
>to decouple ourselves from the assumptions/difficulties of pre-supplied
>kernel headers on random distros Mutant-Linux (etc) was to ship our own.
>
>
Yep, which is why option 2 is to ship someone else's (small, simple)
libc with Valgrind. We get the option to patch it if it has really
unwanted behaviour, but otherwise leave it untouched.
> x86/state.c: ptrace, in ptrace_setregs_from_tst
> -- not sure what this is for; it does not look to me like
> "primary functionality" though
>
>
That's part of the attach-gdb stuff. That should all be hidden behind a
single arch/OS-specific attach_db() interface. And it should be a vki
header rather than a libc one.
> x86-linux/core_platform.h: setjmp.h (setjmp, longjmp, jmp_buf)
> -- we need a setjmp/longjmp facility. 1.0.X used GCC's
> __builtin_setjmp/__builtin_longjmp to avoid this
> dependency; am surprised it is back.
>
>
setjmp is pretty harmless; it does what you'd expect (ie, copies values
between register and memory). sigsetjmp plays with signal state, which
is unwanted. We could switch back to using __builtin_set/longjmp; I
changed it for a bit because I was using longjmp's ability to pass a
value back to setjmp (__builtin_longjmp can only pass back '1'), but
decided to do it another way in the end.
> vg_symtab2.c: elf.h, for ELF types/structs/consts, no fns
> -- seems fairly harmless, conceivably we could copy the headers
> if need be
>
> vg_stabs.c: a.out.h, for stabs types/structs/consts, no fns
> -- ditto
>
> stage1.c: not sure this is a problem
> -- stage1 can use what it likes since stage2 completely
> gets rid of it at startup.
>
> vg_ume.c:
> fprintf exit open perror read close sscanf strchr malloc
> assert pread strerror memcmp memset free mmap strdup printf
> geteuid getegid getgroups stderr errno
>
> These all look like stuff we either do supply ourselves or
> could easily do
>
>
The only complexity is that ume.c is used from both stage1 and stage2,
so replacing these calls would mean linking our home-rolled libc into
stage1 as well. Also, a lot of them are redundant; the scanf is used as
part of the /proc/self/maps parser, but it should probably just use
parseprocselfmaps.
> vg_main.c:
> fork ptrace kill fprintf mmap munmap snprintf fstat malloc
> read close getenv printf strlen memcmp free access strdup strchr
> opendir strerror readdir strncmp closedir dlopen dlerror dlsym
> dlclose abort
>
> Apart from ptrace (what's that for? is it essential) the
> dl* functions are the only worrying ones.
>
>
Most of these are used before Valgrind's internal infrastructure is up.
If the internal allocator can be initialized much eariler, then we can
use our own versions of a lot of these.
>Most of the glibc functions we use, we already have or can easily
>supply. The only stuff which is worrying is:
>
> setjmp / longjmp
>
>
We can go back to using the builtin versions, no problem.
> dlopen/dlsym/dlclose
>
>
Pretty unavoidable, and these have been surprisingly non-troublesome (I
can't think of an instance of a distro-specific bug being in unable to
load a tool .so).
> ptrace, possibly
>
>
Should be deeply hidden in a platform-specific corner.
J
|
|
From: Greg P. <gp...@us...> - 2005-03-31 19:21:01
|
Julian Seward writes: > * What happens on platforms where there is no glibc? MacOSX > and the BSDs? Solaris? Using the native libc on Mac OS X is hard. Valgrind can't share the client's libc because of data collisions and deadlocks. It's hard for Valgrind to load its own copy of libc because libc is a specially built library with difficult contraints on its position in the address space. I'd recommend that Valgrind duplicate any necessary libc functionality, especially if the requirements remain small. > Most of the glibc functions we use, we already have or can easily > supply. The only stuff which is worrying is: > > setjmp / longjmp These can be duplicated without too much trouble. They're processor-specific, but small and well-understood. > dlopen/dlsym/dlclose These are in the dynamic linker on Mac OS X, not libc, and Valgrind does load its own copy of the dynamic linker. Not a problem for Mac OS X. > ptrace, possibly I'm not sure how much of ptrace() actually works on Mac OS X. -- Greg Parker gp...@us... |
|
From: Tom H. <th...@cy...> - 2005-03-31 19:01:18
|
Nightly build on audi ( athlon, Red Hat 9 ) started at 2005-03-31 19:54:30 BST Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 184 tests, 6 stderr failures, 0 stdout failures ================= memcheck/tests/scalar (stderr) cachegrind/tests/chdir (stderr) cachegrind/tests/dlclose (stderr) cachegrind/tests/x86/fpu-28-108 (stderr) none/tests/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2005-03-31 18:57:39
|
Nightly build on alvis ( unknown, Red Hat 7.3 ) started at 2005-03-31 19:56:01 BST Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... failed Last 20 lines of log.verbose follow signals.c:429: warning: implicit declaration of function `vgPlain_defined_new_mem_stack_signal' signals.c:429: warning: implicit declaration of function `vgToolInternal_new_mem_stack_signal' signals.c: In function `build_sigframe': signals.c:476: warning: implicit declaration of function `vgPlain_defined_pre_mem_write' signals.c:476: warning: implicit declaration of function `vgToolInternal_pre_mem_write' signals.c:498: warning: implicit declaration of function `vgPlain_defined_post_mem_write' signals.c:498: warning: implicit declaration of function `vgToolInternal_post_mem_write' signals.c: In function `vgArch_push_signal_frame': signals.c:579: warning: implicit declaration of function `vgPlain_defined_post_reg_write' signals.c:579: warning: implicit declaration of function `vgToolInternal_post_reg_write' signals.c: In function `vgArch_signal_return': signals.c:688: warning: implicit declaration of function `vgPlain_defined_die_mem_stack_signal' signals.c:688: warning: implicit declaration of function `vgToolInternal_die_mem_stack_signal' signals.c:697: warning: implicit declaration of function `vgPlain_defined_post_deliver_signal' signals.c:697: warning: implicit declaration of function `vgToolInternal_post_deliver_signal' make[2]: *** [libarch_a-signals.o] Error 1 make[2]: Leaving directory `/tmp/valgrind.25266/valgrind/coregrind/x86' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.25266/valgrind/coregrind' make: *** [install-recursive] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-31 18:57:24
|
Nightly build on standard ( unknown, Red Hat 7.2 ) started at 2005-03-31 19:55:54 BST Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... failed Last 20 lines of log.verbose follow signals.c:429: warning: implicit declaration of function `vgPlain_defined_new_mem_stack_signal' signals.c:429: warning: implicit declaration of function `vgToolInternal_new_mem_stack_signal' signals.c: In function `build_sigframe': signals.c:476: warning: implicit declaration of function `vgPlain_defined_pre_mem_write' signals.c:476: warning: implicit declaration of function `vgToolInternal_pre_mem_write' signals.c:498: warning: implicit declaration of function `vgPlain_defined_post_mem_write' signals.c:498: warning: implicit declaration of function `vgToolInternal_post_mem_write' signals.c: In function `vgArch_push_signal_frame': signals.c:579: warning: implicit declaration of function `vgPlain_defined_post_reg_write' signals.c:579: warning: implicit declaration of function `vgToolInternal_post_reg_write' signals.c: In function `vgArch_signal_return': signals.c:688: warning: implicit declaration of function `vgPlain_defined_die_mem_stack_signal' signals.c:688: warning: implicit declaration of function `vgToolInternal_die_mem_stack_signal' signals.c:697: warning: implicit declaration of function `vgPlain_defined_post_deliver_signal' signals.c:697: warning: implicit declaration of function `vgToolInternal_post_deliver_signal' make[2]: *** [libarch_a-signals.o] Error 1 make[2]: Leaving directory `/tmp/valgrind.25784/valgrind/coregrind/x86' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.25784/valgrind/coregrind' make: *** [install-recursive] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-31 18:56:26
|
Nightly build on ginetta ( athlon, Red Hat 8.0 ) started at 2005-03-31 19:54:35 BST Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... failed Last 20 lines of log.verbose follow signals.c:429: warning: implicit declaration of function `vgPlain_defined_new_mem_stack_signal' signals.c:429: warning: implicit declaration of function `vgToolInternal_new_mem_stack_signal' signals.c: In function `build_sigframe': signals.c:476: warning: implicit declaration of function `vgPlain_defined_pre_mem_write' signals.c:476: warning: implicit declaration of function `vgToolInternal_pre_mem_write' signals.c:498: warning: implicit declaration of function `vgPlain_defined_post_mem_write' signals.c:498: warning: implicit declaration of function `vgToolInternal_post_mem_write' signals.c: In function `vgArch_push_signal_frame': signals.c:579: warning: implicit declaration of function `vgPlain_defined_post_reg_write' signals.c:579: warning: implicit declaration of function `vgToolInternal_post_reg_write' signals.c: In function `vgArch_signal_return': signals.c:688: warning: implicit declaration of function `vgPlain_defined_die_mem_stack_signal' signals.c:688: warning: implicit declaration of function `vgToolInternal_die_mem_stack_signal' signals.c:697: warning: implicit declaration of function `vgPlain_defined_post_deliver_signal' signals.c:697: warning: implicit declaration of function `vgToolInternal_post_deliver_signal' make[2]: *** [libarch_a-signals.o] Error 1 make[2]: Leaving directory `/tmp/valgrind.18488/valgrind/coregrind/x86' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.18488/valgrind/coregrind' make: *** [install-recursive] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-31 18:49:11
|
Nightly build on audi ( athlon, Red Hat 9 ) started at 2005-03-31 19:48:48 BST Checking out vex source tree ... done Building vex ... failed Last 20 lines of log.verbose follow A vex/auxprogs/genoffsets.c A vex/COPYING A vex/test_main.h A vex/Makefile-icc A vex/Makefile Checked out revision 1115. /tmp/valgrind.32004/vex rm -f priv/ir/irdefs.o priv/ir/irmatch.o priv/ir/iropt.o priv/main/vex_main.o priv/main/vex_globals.o priv/main/vex_util.o priv/host-x86/hdefs.o priv/host-amd64/hdefs.o priv/host-arm/hdefs.o priv/host-ppc32/hdefs.o priv/host-x86/isel.o priv/host-amd64/isel.o priv/host-arm/isel.o priv/host-ppc32/isel.o priv/host-generic/h_generic_regs.o priv/host-generic/h_generic_simd64.o priv/host-generic/reg_alloc2.o priv/guest-generic/g_generic_x87.o priv/guest-x86/ghelpers.o priv/guest-amd64/ghelpers.o priv/guest-arm/ghelpers.o priv/guest-ppc32/ghelpers.o priv/guest-x86/toIR.o priv/guest-amd64/toIR.o priv/guest-arm/toIR.o priv/guest-ppc32/toIR.o libvex.a vex test_main.o \ priv/main/vex_svnversion.h \ pub/libvex_guest_offsets.h rm -f priv/main/vex_svnversion.h echo -n "\"" > priv/main/vex_svnversion.h svnversion -n . >> priv/main/vex_svnversion.h echo "\"" >> priv/main/vex_svnversion.h gcc -Wall -g -o auxprogs/genoffsets auxprogs/genoffsets.c ./auxprogs/genoffsets > pub/libvex_guest_offsets.h gcc -g -O -Wall -Wmissing-prototypes -Wshadow -Winline -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wmissing-declarations -fpie -Ipub -Ipriv -o priv/ir/irdefs.o \ -c priv/ir/irdefs.c cc1: unrecognized option `-fpie' make: *** [priv/ir/irdefs.o] Error 1 |
|
From: Julian S. <js...@ac...> - 2005-03-31 17:40:09
|
On Thursday 31 March 2005 18:20, Nicholas Nethercote wrote: > On Thu, 31 Mar 2005, Tom Hughes wrote: > > I've got nightly builds running on two amd64 boxes now, one running > > on Fedora Core 2 and one Fedora Core 3. > > > > I will also get my x86/FC3 box running nightly builds from the > > new repository, and the other x86 boxes once I've got subversion > > sorted out for them - the RH73 and RH9 boxes are likely to go > > away soon though and the RH72 box may do. > > > > The question is, do we still want nightly builds from the old > > repository as well or shall I just switch the x86 boxes over to > > only building from the new one? > > I guess it doesn't hurt while we're still using CVS for the 2.4 line? I agree. As long as 2.4 is alive we should nightly-build it. Tom, is it possible for you to set up a nightly build for 3.0 on x86? J |
|
From: Nicholas N. <nj...@cs...> - 2005-03-31 17:31:34
|
On Thu, 31 Mar 2005, Julian Seward wrote: > (*) >> Hmm... we were just discussing how having all the arch-specific code in >> one module/directory wasn't really the right thing to do -- that it's >> better to follow modules boundaries, and possibly have some arch-specific >> code in each module. >> >> Isn't there a similar situation here? Ie. really the module (or modules) >> here is our libc replacement or 'utility' module(s) or whatever you want >> to call it. In which case we shouldn't have a separate kal/ directory >> just for the arch-specific things. Does that make sense? > > Uh ... confused. The above proposal, and what Tom has done, does > indeed accord with the para marked (*). It's just that for kal there > may not be much generic code, and so perhaps kal/any_other_name.c > might be a bit thin, but in principle it still exists. In that case, shouldn't the module be called "libc" or "Utility" or something, instead of "KAL"? Perhaps the term "kernel abstraction layer" is confusing, since it gives the idea too much weight. Do we need a separate "kernel abstraction layer", or do we just need a libc/utility module which happens to have some (possibly many) arch/OS/platform specific bits? I'm not sure if I've explained that any more clearly. N |
|
From: Nicholas N. <nj...@cs...> - 2005-03-31 17:21:09
|
On Thu, 31 Mar 2005, Tom Hughes wrote: > I've got nightly builds running on two amd64 boxes now, one running > on Fedora Core 2 and one Fedora Core 3. > > I will also get my x86/FC3 box running nightly builds from the > new repository, and the other x86 boxes once I've got subversion > sorted out for them - the RH73 and RH9 boxes are likely to go > away soon though and the RH72 box may do. > > The question is, do we still want nightly builds from the old > repository as well or shall I just switch the x86 boxes over to > only building from the new one? I guess it doesn't hurt while we're still using CVS for the 2.4 line? N |
|
From: Nicholas N. <nj...@cs...> - 2005-03-31 17:17:29
|
On Thu, 31 Mar 2005, Tom Hughes wrote:
>>> +PRE(sys_gettid, 0)
>>> +{
>>> + PRINT("sys_gettid ()");
>>> + PRE_REG_READ0(long, "gettid");
>>> +}
>>> +
>>
>> It does nothing? Surely there should be a comment explaining what is
>> happening here?
>
> Of course it does something - after the pre handler runs the system
> call will be run in the usual way and return a result. With the new
> threading model no special handling is needed for gettid.
Ok... I'll engage my brain before commenting next time :)
N
|
|
From: <sv...@va...> - 2005-03-31 16:02:20
|
Author: tom
Date: 2005-03-31 17:02:07 +0100 (Thu, 31 Mar 2005)
New Revision: 3493
Modified:
trunk/coregrind/amd64-linux/syscalls.c
trunk/coregrind/core.h
trunk/coregrind/linux/core_os.h
trunk/coregrind/linux/syscalls.c
trunk/coregrind/vg_syscalls.c
trunk/coregrind/x86-linux/syscalls.c
Log:
Move the gettid system call to the linux specific section.
Modified: trunk/coregrind/amd64-linux/syscalls.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/amd64-linux/syscalls.c 2005-03-31 15:48:57 UTC (rev 3=
492)
+++ trunk/coregrind/amd64-linux/syscalls.c 2005-03-31 16:02:07 UTC (rev 3=
493)
@@ -1109,7 +1109,7 @@
// (__NR_tuxcall, sys_ni_syscall), // 184
=20
// (__NR_security, sys_ni_syscall), // 185=20
- // (__NR_gettid, sys_gettid), // 186=20
+ LINX_(__NR_gettid, sys_gettid), // 186=20
// (__NR_readahead, sys_readahead), // 187=20
// (__NR_setxattr, sys_setxattr), // 188=20
// (__NR_lsetxattr, sys_lsetxattr), // 189=20
Modified: trunk/coregrind/core.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/core.h 2005-03-31 15:48:57 UTC (rev 3492)
+++ trunk/coregrind/core.h 2005-03-31 16:02:07 UTC (rev 3493)
@@ -1418,7 +1418,6 @@
GEN_SYSCALL_WRAPPER(sys_mq_timedreceive); // * P?
GEN_SYSCALL_WRAPPER(sys_mq_notify); // * P?
GEN_SYSCALL_WRAPPER(sys_mq_getsetattr); // * P?
-GEN_SYSCALL_WRAPPER(sys_gettid); // * L?
=20
#undef GEN_SYSCALL_WRAPPER
=20
Modified: trunk/coregrind/linux/core_os.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/linux/core_os.h 2005-03-31 15:48:57 UTC (rev 3492)
+++ trunk/coregrind/linux/core_os.h 2005-03-31 16:02:07 UTC (rev 3493)
@@ -82,6 +82,7 @@
VGO_LINUX_SYSCALL_WRAPPER(sys_epoll_ctl);
VGO_LINUX_SYSCALL_WRAPPER(sys_epoll_wait);
=20
+VGO_LINUX_SYSCALL_WRAPPER(sys_gettid);
VGO_LINUX_SYSCALL_WRAPPER(sys_tkill);
VGO_LINUX_SYSCALL_WRAPPER(sys_tgkill);
=20
Modified: trunk/coregrind/linux/syscalls.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/linux/syscalls.c 2005-03-31 15:48:57 UTC (rev 3492)
+++ trunk/coregrind/linux/syscalls.c 2005-03-31 16:02:07 UTC (rev 3493)
@@ -503,6 +503,12 @@
POST_MEM_WRITE( ARG2, sizeof(struct epoll_event)*RES ) ;
}
=20
+PRE(sys_gettid, 0)
+{
+ PRINT("sys_gettid ()");
+ PRE_REG_READ0(long, "gettid");
+}
+
PRE(sys_tkill, Special)
{
/* int tkill(pid_t tid, int sig); */
Modified: trunk/coregrind/vg_syscalls.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/vg_syscalls.c 2005-03-31 15:48:57 UTC (rev 3492)
+++ trunk/coregrind/vg_syscalls.c 2005-03-31 16:02:07 UTC (rev 3493)
@@ -2956,12 +2956,6 @@
RES =3D 1;
}
=20
-PRE(sys_gettid, 0)
-{
- PRINT("sys_gettid ()");
- PRE_REG_READ0(long, "gettid");
-}
-
static void common_post_getrlimit(ThreadId tid, UWord a1, UWord a2)
{
POST_MEM_WRITE( a2, sizeof(struct vki_rlimit) );
Modified: trunk/coregrind/x86-linux/syscalls.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/x86-linux/syscalls.c 2005-03-31 15:48:57 UTC (rev 349=
2)
+++ trunk/coregrind/x86-linux/syscalls.c 2005-03-31 16:02:07 UTC (rev 349=
3)
@@ -1246,7 +1246,7 @@
GENXY(__NR_fcntl64, sys_fcntl64), // 221
GENX_(222, sys_ni_syscall), // 222
GENX_(223, sys_ni_syscall), // 223
- GENX_(__NR_gettid, sys_gettid), // 224 */Linux
+ LINX_(__NR_gettid, sys_gettid), // 224
=20
// (__NR_readahead, sys_readahead), // 225 */(Linux?)
GENX_(__NR_setxattr, sys_setxattr), // 226
|
|
From: Julian S. <js...@ac...> - 2005-03-31 15:53:24
|
> One thing that is odd is that I think that should be a linux specific > system call but the 2.4 code definitely has it in the generic ones and > the "Linux" marker against the entry in x86-linux/syscalls.c is > missing in the 2.4 code base but present in the 3.0 code base. That's probably a me-induced merge bogon -- the "Linux" marker might have come from my code line but the actual location of it from the 2.4 line. I agree, it should be a linux-specific one. J |
|
From: <sv...@va...> - 2005-03-31 15:49:01
|
Author: sewardj
Date: 2005-03-31 16:48:57 +0100 (Thu, 31 Mar 2005)
New Revision: 3492
Modified:
trunk/coregrind/vg_translate.c
Log:
Increase maximum translation size. This can happen when translating
long sequences of x86 insns with IR optimisation disabled, so the
tag-checking crap doesn't get knocked out like it usually does.
Modified: trunk/coregrind/vg_translate.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/vg_translate.c 2005-03-31 10:19:59 UTC (rev 3491)
+++ trunk/coregrind/vg_translate.c 2005-03-31 15:48:57 UTC (rev 3492)
@@ -277,7 +277,7 @@
=20
/* Vex dumps the final code in here. Then we can copy it off
wherever we like. */
-#define N_TMPBUF 10000
+#define N_TMPBUF 20000
static UChar tmpbuf[N_TMPBUF];
=20
/* Function pointers we must supply to LibVEX in order that it
|
|
From: Tom H. <to...@co...> - 2005-03-31 15:40:18
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> On Thu, 31 Mar 2005 sv...@va... wrote:
>
>> +PRE(sys_gettid, 0)
>> +{
>> + PRINT("sys_gettid ()");
>> + PRE_REG_READ0(long, "gettid");
>> +}
>> +
>
> It does nothing? Surely there should be a comment explaining what is
> happening here?
Of course it does something - after the pre handler runs the system
call will be run in the usual way and return a result. With the new
threading model no special handling is needed for gettid.
One thing that is odd is that I think that should be a linux specific
system call but the 2.4 code definitely has it in the generic ones and
the "Linux" marker against the entry in x86-linux/syscalls.c is
missing in the 2.4 code base but present in the 3.0 code base.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: <sv...@va...> - 2005-03-31 15:31:59
|
Author: de
Date: 2005-03-31 16:31:53 +0100 (Thu, 31 Mar 2005)
New Revision: 102
Modified:
trunk/info/developers.html
Log:
Added Paul M's email address to the Developers Page
Modified: trunk/info/developers.html
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/info/developers.html 2005-03-30 18:44:53 UTC (rev 101)
+++ trunk/info/developers.html 2005-03-31 15:31:53 UTC (rev 102)
@@ -48,7 +48,7 @@
=20
<tr valign=3D"top">
<td><b>Paul Mackerras</b><br />
- </td>
+ <?php echo vgemail('paulus'); ?></td>
<td>Paul did a lot of the initial per-architecture factoring that
forms the basis of the 3.0 line and is also to be seen in 2.4.0.
He also did UCode-based dynamic translation support for PowerPC,
|
|
From: Nicholas N. <nj...@cs...> - 2005-03-31 14:57:21
|
On Thu, 31 Mar 2005, Tom Hughes wrote: >>> I had to move the tool header file to the main includes directory >>> so the tools could see it. >> >> Which header file is that? tool.h is already in include/ ... > > The pub_tool_kal.h one that Julian described in the original design. Ah, that's fine. > There are already pub_tool_execontext.h and pub_tool_stacktrace.h > files in there which I think came from you didn't they? Yep. N |
|
From: Nicholas N. <nj...@cs...> - 2005-03-31 14:55:42
|
On Thu, 31 Mar 2005 sv...@va... wrote:
> +PRE(sys_gettid, 0)
> +{
> + PRINT("sys_gettid ()");
> + PRE_REG_READ0(long, "gettid");
> +}
> +
It does nothing? Surely there should be a comment explaining what is
happening here?
N
|
|
From: Nicholas N. <nj...@cs...> - 2005-03-31 14:54:20
|
On Thu, 31 Mar 2005 sv...@va... wrote: > Modified: > trunk/helgrind/hg_main.c > Log: > Update helgrind to use the new mechanism to declare it's interface > routines to the core so that it will at least build. Sorry... I forgot to rerun autoconf/automake... N |
|
From: Tom H. <to...@co...> - 2005-03-31 14:50:09
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> On Thu, 31 Mar 2005, Tom Hughes wrote:
>
>> I've got an updated patch now - it's getting a bit large so I've
>> gzipped it and put it on the web at:
>>
>> http://www.compton.nu/kal.patch.gz
>>
>> It builds on x86 and amd64. There is still work to be done removing
>> the vki structures from the kal interface but the error handling is
>> there and the stub routines in mylibc have been removed.
>>
>> I had to move the tool header file to the main includes directory
>> so the tools could see it.
>
> Which header file is that? tool.h is already in include/ ...
The pub_tool_kal.h one that Julian described in the original design.
There are already pub_tool_execontext.h and pub_tool_stacktrace.h
files in there which I think came from you didn't they?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-03-31 14:48:20
|
On Thu, 31 Mar 2005, Tom Hughes wrote: > I've got an updated patch now - it's getting a bit large so I've > gzipped it and put it on the web at: > > http://www.compton.nu/kal.patch.gz > > It builds on x86 and amd64. There is still work to be done removing > the vki structures from the kal interface but the error handling is > there and the stub routines in mylibc have been removed. > > I had to move the tool header file to the main includes directory > so the tools could see it. Which header file is that? tool.h is already in include/ ... N |
|
From: Julian S. <js...@ac...> - 2005-03-31 14:13:17
|
On Thursday 31 March 2005 05:35, Nicholas Nethercote wrote: > On Wed, 30 Mar 2005, Tom Hughes wrote: > >> Instead, it would be better to put the Kal module/subsystem > >> in its own directory, kal, and put all the arch/os specific bits > >> just for Kal in there: > >> > >> kal/pub_core_kal.h -- services exported from kal; core but not > >> tools may use these > >> kal/pub_tool_kal.h -- services exported from kal; both core and > >> tools may use these > >> > >> kal/kal-x86-linux.c -- x86-linux specific implementation > >> kal/kal-amd64-linux.c -- amd64-linux specific implementation > >> kal/any_other_name.c -- generic implementation > (*) > Hmm... we were just discussing how having all the arch-specific code in > one module/directory wasn't really the right thing to do -- that it's > better to follow modules boundaries, and possibly have some arch-specific > code in each module. > > Isn't there a similar situation here? Ie. really the module (or modules) > here is our libc replacement or 'utility' module(s) or whatever you want > to call it. In which case we shouldn't have a separate kal/ directory > just for the arch-specific things. Does that make sense? Uh ... confused. The above proposal, and what Tom has done, does indeed accord with the para marked (*). It's just that for kal there may not be much generic code, and so perhaps kal/any_other_name.c might be a bit thin, but in principle it still exists. Am I missing something? I suppose there's an ambiguity -- as yet unresolved -- as to whether the vanilla stuff like VG_(strlen) etc should be in kal, in which case it would have to be in the vanilla parts of kal, or not. Personally I don't think so; strlen et al are just utility functions and have nothing to do with the kernel interface. To say it another way, the standard libc interface provides both vanilla utilities and kernel wrappers, and we are considering, at least, splitting that interface into two different parts. J |
|
From: Tom H. <to...@co...> - 2005-03-31 10:40:58
|
I've got nightly builds running on two amd64 boxes now, one running on Fedora Core 2 and one Fedora Core 3. I will also get my x86/FC3 box running nightly builds from the new repository, and the other x86 boxes once I've got subversion sorted out for them - the RH73 and RH9 boxes are likely to go away soon though and the RH72 box may do. The question is, do we still want nightly builds from the old repository as well or shall I just switch the x86 boxes over to only building from the new one? Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Tom H. <th...@cy...> - 2005-03-31 10:36:52
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2005-03-31 11:33:19 BST Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 165 tests, 86 stderr failures, 25 stdout failures ================= memcheck/tests/addressable (stdout) memcheck/tests/addressable (stderr) memcheck/tests/badaddrvalue (stdout) memcheck/tests/badaddrvalue (stderr) memcheck/tests/badfree-2trace (stderr) memcheck/tests/badfree (stderr) memcheck/tests/badjump (stderr) memcheck/tests/badjump2 (stderr) memcheck/tests/badloop (stderr) memcheck/tests/badpoll (stderr) memcheck/tests/badrw (stderr) memcheck/tests/brk (stderr) memcheck/tests/brk2 (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/clientperm (stdout) memcheck/tests/clientperm (stderr) memcheck/tests/custom_alloc (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/doublefree (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/errs1 (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/exitprog (stderr) memcheck/tests/fprw (stderr) memcheck/tests/fwrite (stdout) memcheck/tests/fwrite (stderr) memcheck/tests/inits (stderr) memcheck/tests/inline (stdout) memcheck/tests/inline (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/malloc1 (stderr) memcheck/tests/malloc2 (stderr) memcheck/tests/malloc3 (stdout) memcheck/tests/malloc3 (stderr) memcheck/tests/manuel1 (stdout) memcheck/tests/manuel1 (stderr) memcheck/tests/manuel2 (stdout) memcheck/tests/manuel2 (stderr) memcheck/tests/manuel3 (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/memalign_test (stderr) memcheck/tests/memcmptest (stdout) memcheck/tests/memcmptest (stderr) memcheck/tests/mempool (stderr) memcheck/tests/metadata (stdout) memcheck/tests/metadata (stderr) memcheck/tests/mismatches (stderr) memcheck/tests/nanoleak (stderr) memcheck/tests/new_override (stdout) memcheck/tests/new_override (stderr) memcheck/tests/overlap (stdout) memcheck/tests/overlap (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/post-syscall (stdout) memcheck/tests/post-syscall (stderr) memcheck/tests/realloc3 (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_exit_group (stderr) memcheck/tests/scalar_fork (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/scalar_vfork (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/signal2 (stdout) memcheck/tests/signal2 (stderr) memcheck/tests/sigprocmask (stderr) memcheck/tests/supp2 (stderr) memcheck/tests/suppfree (stderr) memcheck/tests/threadederrno (stdout) memcheck/tests/toobig-allocs (stderr) memcheck/tests/trivialleak (stderr) memcheck/tests/vgtest_ume (stderr) memcheck/tests/weirdioctl (stdout) memcheck/tests/weirdioctl (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stdout) addrcheck/tests/addressable (stdout) addrcheck/tests/addressable (stderr) addrcheck/tests/badrw (stderr) addrcheck/tests/fprw (stderr) addrcheck/tests/leak-0 (stderr) addrcheck/tests/leak-cycle (stderr) addrcheck/tests/leak-regroot (stderr) addrcheck/tests/leak-tree (stderr) addrcheck/tests/overlap (stdout) addrcheck/tests/overlap (stderr) addrcheck/tests/toobig-allocs (stderr) cachegrind/tests/chdir (stderr) cachegrind/tests/dlclose (stderr) corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_dup2 (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_open (stderr) corecheck/tests/fdleak_pipe (stderr) corecheck/tests/fdleak_socketpair (stderr) corecheck/tests/res_search (stdout) corecheck/tests/res_search (stderr) massif/tests/toobig-allocs (stderr) none/tests/faultstatus (stderr) none/tests/resolv (stdout) none/tests/resolv (stderr) none/tests/selfrun (stdout) none/tests/selfrun (stderr) none/tests/yield (stdout) |