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: Nicholas N. <nj...@cs...> - 2005-03-30 15:15:43
|
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 > > How are we going to decide what is and isn't exported? Do we make > everything core only to start with and move it to the tool header > if a tool needs it? or make everything available to tools unless > we have some reason to believe it can only work in the core? The former; the tool should see as little as possible. That's how it has been done in core.h and tool.h. >> 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 > > I'm not sure you can have a generic implementation of anything in the > kernel abstraction layer ;-) I guess it depends on whether you keep as a separate layer, as you did in the patch, or fold that into KAL. N |
|
From: <sv...@va...> - 2005-03-30 15:06:08
|
Author: tom
Date: 2005-03-30 16:05:46 +0100 (Wed, 30 Mar 2005)
New Revision: 3481
Modified:
trunk/coregrind/vg_dwarf.c
trunk/coregrind/vg_symtab2.c
Log:
Get thew DWARF reading going on 64 bit machines.
Modified: trunk/coregrind/vg_dwarf.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_dwarf.c 2005-03-30 08:22:38 UTC (rev 3480)
+++ trunk/coregrind/vg_dwarf.c 2005-03-30 15:05:46 UTC (rev 3481)
@@ -159,7 +159,7 @@
of sequence. */
static=20
int process_extended_line_op( SegInfo *si, Char*** fnames,=20
- UChar* data, Int is_stmt, Int pointer_size=
)
+ UChar* data, Int is_stmt)
{
UChar op_code;
Int bytes_read;
@@ -201,10 +201,6 @@
break;
=20
case DW_LNE_set_address:
- /* XXX: Pointer size could be 8 */
- // (and there may be other 32-bit assumptions within this file?
- // not sure... --njn)
- vg_assert(pointer_size =3D=3D 4);
adr =3D *((Addr *)data);
if (0) VG_(printf)("smr.a :=3D %p\n", adr );
state_machine_regs.address =3D adr;
@@ -214,11 +210,11 @@
++ state_machine_regs.last_file_entry;
name =3D data;
if (*fnames =3D=3D NULL)
- *fnames =3D VG_(arena_malloc)(VG_AR_SYMTAB, sizeof (UInt) * 2);
+ *fnames =3D VG_(arena_malloc)(VG_AR_SYMTAB, sizeof (Char *) * 2)=
;
else
*fnames =3D VG_(arena_realloc)(
VG_AR_SYMTAB, *fnames,
- sizeof(UInt) * (state_machine_regs.last_file_entry =
+ 1));
+ sizeof(Char *) * (state_machine_regs.last_file_entr=
y + 1));
(*fnames)[state_machine_regs.last_file_entry] =3D VG_(addStr) (si,=
name, -1);
data +=3D VG_(strlen) ((char *) data) + 1;
read_leb128 (data, & bytes_read, 0);
@@ -366,10 +362,10 @@
semantics, we need to malloc the first time. */
=20
if (fnames =3D=3D NULL)
- fnames =3D VG_(arena_malloc)(VG_AR_SYMTAB, sizeof (UInt) =
* 2);
+ fnames =3D VG_(arena_malloc)(VG_AR_SYMTAB, sizeof (Char *=
) * 2);
else
fnames =3D VG_(arena_realloc)(VG_AR_SYMTAB, fnames,
- sizeof(UInt)=20
+ sizeof(Char *)=20
* (state_machine_regs.last_file_entry + 1)=
);
data +=3D VG_(strlen) ((Char *) data) + 1;
fnames[state_machine_regs.last_file_entry] =3D VG_(addStr) =
(si,name, -1);
@@ -433,7 +429,7 @@
case DW_LNS_extended_op:
data +=3D process_extended_line_op (
si, &fnames, data,=20
- info.li_default_is_stmt, sizeof (Addr));
+ info.li_default_is_stmt);
break;
=20
case DW_LNS_copy:
Modified: trunk/coregrind/vg_symtab2.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_symtab2.c 2005-03-30 08:22:38 UTC (rev 3480)
+++ trunk/coregrind/vg_symtab2.c 2005-03-30 15:05:46 UTC (rev 3481)
@@ -1531,7 +1531,7 @@
VG_(read_debuginfo_stabs) ( si, stab, stab_sz,=20
stabstr, stabstr_sz );
}
- if (debug_line && VGA_WORD_SIZE=3D=3D4/*hack*/) {
+ if (debug_line) {
has_debuginfo =3D True;
VG_(read_debuginfo_dwarf2) ( si, debug_line, debug_line_sz );
}
|
|
From: Nicholas N. <nj...@cs...> - 2005-03-30 15:02:48
|
On Wed, 30 Mar 2005, Jeremy Fitzhardinge wrote: > Even assuming the "all-or-none" condition is really invarient for all these > VG_(*_funcs)() functions, which I'm unconvinced about, I think functions with > lots of arguments are inherently unreadable and hard to maintain. I'd really > prefer to go with structures of pointers to functions: at least you can name > the fields and order isn't important. (At the very very least, the redzone > arg to VG_(malloc_funcs)() should be first, so that new allocators can be > added without having to move it, or embed it in the middle of unrelated > arguments.) Giving the tool direct access to the VG_(tool_interface) struct doesn't seem like a good idea -- it exposes it to more than it needs to see. So this would simply separate structs corresponding to each of the multi-arg functions in the patch now. Only two of those functions are really bad -- VG_(needs_tool_errors)() has 8 args, VG_(malloc_funcs)() has 10. Do you think we need structs for the ones with only 1, 2 or 3 args? N |
|
From: Tom H. <to...@co...> - 2005-03-30 13:17:58
|
In message <424...@go...>
Jeremy Fitzhardinge <je...@go...> wrote:
> If nothing else, the kal_* functions may as well be called
> VG_(getpid)(), etc, rather than either changing all the callers or
> having a file full of stub functions.
I was a bit unsure whether or not to get rid of the libc layer
altogether - in many cases it makes sense as the routines are
just stubs to forward to the KAL routines but some like mmap
and friends have extra logic in the libc layer to update the
segment mappings and similar.
>> Int VG_(getppid) ( void )
>> {
>>- Int res;
>>- res = VG_(do_syscall0)(__NR_getppid);
>>- return res;
>>+ return VG_(getppid)();
>> }
>>
> This might take a while to terminate...
Fixed in my local tree.
>>+Addr VG_(kal_mmap)(Addr start, SizeT length, UInt prot, UInt flags,
>>+ UInt fd, OffT offset)
>>+{
>>+ UWord args[6];
>>+
>>+ args[0] = start;
>>+ args[1] = length;
>>+ args[2] = prot;
>>+ args[3] = flags;
>>+ args[4] = fd;
>>+ args[5] = offset;
>>+
>>+ return VG_(do_syscall1)(__NR_mmap, (UWord)args);
>>+}
>>
> I think mmap2 would be preferable here.
The code was all copied from what the libc code was already doing
but you're probably right. It might make sense to use rt_sigpending
on x86 as well, that way we can share with amd64. The other signal
routines already use the rt version anyway.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-03-30 13:12:50
|
In message <200...@ac...>
Julian Seward <js...@ac...> 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
How are we going to decide what is and isn't exported? Do we make
everything core only to start with and move it to the tool header
if a tool needs it? or make everything available to tools unless
we have some reason to believe it can only work in the core?
> 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
I'm not sure you can have a generic implementation of anything in the
kernel abstraction layer ;-)
I also added a kal-linux.c for things common to all linux builds
regardless of architecture.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Jeremy F. <je...@go...> - 2005-03-30 09:59:53
|
Tom Hughes wrote:
>Like the attached patch you mean? That still adds loads to the
>fast path because you have to load the address from the GOT before
>you can use it.
>
>
Yep, that looks about right. I wasn't too worried about adding a couple
of extra instructions here because BB-chaining should take most of the
load off this code (in 2.4); in 3, one presumes Vex's BB-fusing is about
as effective (or we need to look at doing chaining as well).
J
|
|
From: Jeremy F. <je...@go...> - 2005-03-30 09:58:04
|
Tom Hughes wrote: >Attached is a first cut at a kernel abstraction layer. It removes >most of the direct system calls from the coregrind directory and >moves them into KAL routines. As a side effect it implements the >missing mylibc functionality for amd64. > >I've made a start on removing VKI types from the KAL interface as >any abstraction layer will need to be independent of the types used >to communicate with the kernel. Many routines still use VKI types >in their interface however. > > I think we should just use the libc API for this, if not the system glibc. Would uclibc be a good basis (http://www.uclibc.org/)? It would get us out of the business of maintaining a C library as well. If nothing else, the kal_* functions may as well be called VG_(getpid)(), etc, rather than either changing all the callers or having a file full of stub functions. > Int VG_(getppid) ( void ) > { >- Int res; >- res = VG_(do_syscall0)(__NR_getppid); >- return res; >+ return VG_(getppid)(); > } > > This might take a while to terminate... >+Addr VG_(kal_mmap)(Addr start, SizeT length, UInt prot, UInt flags, >+ UInt fd, OffT offset) >+{ >+ UWord args[6]; >+ >+ args[0] = start; >+ args[1] = length; >+ args[2] = prot; >+ args[3] = flags; >+ args[4] = fd; >+ args[5] = offset; >+ >+ return VG_(do_syscall1)(__NR_mmap, (UWord)args); >+} > > I think mmap2 would be preferable here. J |
|
From: Tom H. <to...@co...> - 2005-03-30 09:51:28
|
In message <yek...@ho...>
Tom Hughes <to...@co...> wrote:
> This patch actually adds four loads. One can be eliminate by looking
> up instr_ptr_offset once at the start and caching it on the stack. The
> dispatch_ctr one could probably be eliminate by keeping a local copy
> of the dispatch counter and updating the global at the end.
Here's an updated version that implements those two suggestions so
that we are only adding two loads to the fast path.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-03-30 09:36:05
|
In message <424...@go...>
Jeremy Fitzhardinge <je...@go...> wrote:
> Tom Hughes wrote:
>
>>Does anybody have any suggestions for a better way to make the code
>>in dispatch.S position independent?
>
> You could just use globals and make position-independent references to
> them. Look at the gcc -S output to see what the syntax is; I have a
> patch somewhere which does this, but I can't find it right now.
Like the attached patch you mean? That still adds loads to the
fast path because you have to load the address from the GOT before
you can use it.
This patch actually adds four loads. One can be eliminate by looking
up instr_ptr_offset once at the start and caching it on the stack. The
dispatch_ctr one could probably be eliminate by keeping a local copy
of the dispatch counter and updating the global at the end.
The tt_fast and tt_fastN ones are a problem however as you don't seem
to be able to do this:
movq VG_(tt_fast)@GOTPCREL(%rip,%rbx,8), %rcx
so you have to do this:
movq VG_(tt_fast)@GOTPCREL(%rip), %rcx
movq (%rcx,%rbx,8), %rcx
and the same for the tt_fastN array.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Jeremy F. <je...@go...> - 2005-03-30 08:50:44
|
Nicholas Nethercote wrote:
> I attach a revised version of my patch, which has a small improvement
> in the way that the size of redzones in the client arena is handled --
> the size is now specified as an argument to VG_(malloc_funcs) rather
> than in the VG_DETERMINE_INTERFACE_VERSION macro, which is much better.
Yes, that's good.
> Otherwise, it's unchanged. What do you both think about the way tool
> functions are registered, given the discussion we've had about the
> constraints involved? As I said before, if I committed this it would
> only be the first step of several. Or, I could do more changes and
> submit a larger patch, so you could see what things would look like
> further along that road. Let me know what you both think.
Even assuming the "all-or-none" condition is really invarient for all
these VG_(*_funcs)() functions, which I'm unconvinced about, I think
functions with lots of arguments are inherently unreadable and hard to
maintain. I'd really prefer to go with structures of pointers to
functions: at least you can name the fields and order isn't important.
(At the very very least, the redzone arg to VG_(malloc_funcs)() should
be first, so that new allocators can be added without having to move it,
or embed it in the middle of unrelated arguments.)
J
|
|
From: Tom H. <to...@co...> - 2005-03-30 08:48:41
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> On Tue, 29 Mar 2005, Julian Seward wrote:
>
>> What I want to happen is for a Kernel-services Abstraction Layer
>> (Kal) to appear. In the same way that Moz has NPSR, OOo has
>> SAL, etc. Kal will provide services like mmap etc whilst hiding
>> the details of how the call is done on different platforms. Of
>> course Kal will be far simpler than NPSR, SAL, etc, but the idea
>> is the same.
>>
>> So that's something worth looking into. I plan to do this myself
>> anyway at some stage, but if you want to look into it, please do.
>
> Tom, perhaps you could generate some patches and post them to the list
> to see how they turn out. It will be interesting to see how much libc
> stuff is platform-specific.
Attached is a first cut at a kernel abstraction layer. It removes
most of the direct system calls from the coregrind directory and
moves them into KAL routines. As a side effect it implements the
missing mylibc functionality for amd64.
I've made a start on removing VKI types from the KAL interface as
any abstraction layer will need to be independent of the types used
to communicate with the kernel. Many routines still use VKI types
in their interface however.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-03-30 05:05:44
|
On Mon, 28 Mar 2005, Julian Seward wrote: > Simplifying the tool interface is definitely a Good Thing To Do. However > I'm not convinced by the objections raised thus far to the struct passing > approach, and I like its simplicity. Reasons below. Jeremy, Julian, I attach a revised version of my patch, which has a small improvement in the way that the size of redzones in the client arena is handled -- the size is now specified as an argument to VG_(malloc_funcs) rather than in the VG_DETERMINE_INTERFACE_VERSION macro, which is much better. Otherwise, it's unchanged. What do you both think about the way tool functions are registered, given the discussion we've had about the constraints involved? As I said before, if I committed this it would only be the first step of several. Or, I could do more changes and submit a larger patch, so you could see what things would look like further along that road. Let me know what you both think. N |
|
From: Tom H. <to...@co...> - 2005-03-30 02:28:37
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2005-03-30 03:20:05 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_cmov: valgrind ./insn_cmov insn_fpu: valgrind ./insn_fpu insn_mmx: valgrind ./insn_mmx insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int sh: line 1: 23659 Segmentation fault VALGRINDLIB=/tmp/valgrind.30973/valgrind/.in_place /tmp/valgrind.30973/valgrind/./coregrind/valgrind --command-line-only=yes --memcheck:leak-check=no --addrcheck:leak-check=no --tool=none ./int >int.stdout.out 2>int.stderr.out pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 207 tests, 2 stderr failures, 0 stdout failures ================= memcheck/tests/scalar (stderr) memcheck/tests/scalar_supp (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-30 02:22:18
|
Nightly build on audi ( Red Hat 9 ) started at 2005-03-30 03:15:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow fpu_lazy_eflags: valgrind ./fpu_lazy_eflags insn_basic: valgrind ./insn_basic insn_cmov: valgrind ./insn_cmov insn_fpu: valgrind ./insn_fpu insn_mmx: valgrind ./insn_mmx insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 206 tests, 1 stderr failure, 0 stdout failures ================= memcheck/tests/scalar (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-30 02:16:25
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2005-03-30 03:10:01 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_cmov: valgrind ./insn_cmov insn_fpu: valgrind ./insn_fpu insn_mmx: valgrind ./insn_mmx insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 205 tests, 3 stderr failures, 0 stdout failures ================= memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-30 02:15:23
|
Nightly build on standard ( Red Hat 7.2 ) started at 2005-03-30 03:00:01 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 205 tests, 6 stderr failures, 0 stdout failures ================= memcheck/tests/leak-tree (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) addrcheck/tests/leak-tree (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-30 02:11:51
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2005-03-30 03:05:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow == 205 tests, 17 stderr failures, 0 stdout failures ================= memcheck/tests/addressable (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/distinguished-writes (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) addrcheck/tests/leak-0 (stderr) addrcheck/tests/leak-cycle (stderr) addrcheck/tests/leak-regroot (stderr) addrcheck/tests/leak-tree (stderr) make: *** [regtest] Error 1 |
|
From: Nicholas N. <nj...@cs...> - 2005-03-30 00:29:18
|
On Tue, 29 Mar 2005, Julian Seward wrote: > What I want to happen is for a Kernel-services Abstraction Layer > (Kal) to appear. In the same way that Moz has NPSR, OOo has > SAL, etc. Kal will provide services like mmap etc whilst hiding > the details of how the call is done on different platforms. Of > course Kal will be far simpler than NPSR, SAL, etc, but the idea > is the same. > > So that's something worth looking into. I plan to do this myself > anyway at some stage, but if you want to look into it, please do. Tom, perhaps you could generate some patches and post them to the list to see how they turn out. It will be interesting to see how much libc stuff is platform-specific. N |