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
(6) |
2
(6) |
3
(10) |
4
(10) |
|
5
(6) |
6
(6) |
7
(9) |
8
(6) |
9
(6) |
10
(7) |
11
(7) |
|
12
(6) |
13
(6) |
14
(8) |
15
(17) |
16
(10) |
17
(17) |
18
(8) |
|
19
(9) |
20
(7) |
21
(6) |
22
(6) |
23
(6) |
24
(5) |
25
(3) |
|
26
(3) |
27
(3) |
28
(3) |
29
(3) |
30
(2) |
31
(3) |
|
|
From: Jeremy F. <je...@go...> - 2004-12-03 21:40:49
|
On Fri, 2004-12-03 at 02:21 -0800, Roland McGrath wrote:
> > The main one is probably working out how to handle the page tables and
> > segments. Need to look at this in more detail.
>
> Page table issues and segmentation issues are really quite separate and I'd
> prefer to address their details independently. The page table handling is
> intertwined with the essential allocation tracking. This is I think where
> the real meat is that determines what several of the other decisions might
> mean. I would like to discuss this in detail before getting too mired in
> the other areas of detail.
I'm not so worried about page table management. Valgrind already needs
to support user-mode programs using mmap, that's just a high-level
interface to the paging hardware. If the client wants to operate on
page tables, then that's OK. The slightly tricky bit will be in dealing
with "writable page table" mode, but it probably isn't any more complex
than the signal virtualization we have now.
Segments are a bit trickier, because Valgrind takes short-cuts. We
assume that ds, es and ss are all flat segments which are identical to
each other, and are never changed. This means that normal memory access
instructions just ignore segmentation, and assume an identity mapping.
We only do segment handling for instructions with explicit segment
overrides, which typically means fs and gs. If a client/guest OS wants
to use segmentation in more complex ways, then it will cost a fair
amount of performance.
> > Hm, will we need to understand multiple code segments?
>
> In the general case, yes. In practice, not really. (And anyway, there
> really isn't all that much to it.) The yes is because the Xen hypercall
> interface is pretty free in what it lets a guest OS do with its segments.
> Loading and using segment registers (including setting %cs with jumps and
> such) are not privileged instructions. There is a hypercall interface to
> load segment descriptor tables of the guest OS's choice. Separate code
> segments can be used both directly in jumps, and in hypercall interface
> when specifying trap handlers.
>
> The not really is because in extant guest OS implementations anyone wants
> to use (such as xen/linux), the kernel code that you want instrumented only
> ever uses the single standard flat code segment.
That's what we assume at the moment. Valgrind maintains a cache of
translated code, which is indexed by eip; like segments for data access,
cs is assumed to be flat and unchanging. If cs changes around, we'd
need to make sure that the translation cache is maintained
appropriately. One wart is that the mode of the CPU (16/32/64?) is a
property of the current cs, and that affects how the instruction bytes
are actually interpreted; if we wanted to support the different sizing
modes, we'd need to make sure that we maintain the translation cache
properly.
At least changes to cs are pretty obvious; when translating any kind of
trap/long jump/call/ret we generate code to observe how cs is changed.
> > Valgrind will need to know a little bit about CPU privilege modes.
>
> This is intertwined with code segments in the x86 world. In fact, for
> practical purposes the only need there will be to support code segment
> changes is when they are used to change privilege mode.
Yes, and fortunately the privilege modes don't affect how the
instructions are interpreted (only whether they trap or not).
> > It should only allow int $0x82 from ring 1. We'll need to emulate the
> > syscall instructions too (or pretend they don't exist).
>
> I'm not clear on where you're headed here. For at least the first crack
> plan, you only want the kernel code itself (ring 1) to be instrumented, and
> when instrumented code switches rings, that should bust you out of
> valgrindland to run user mode normally on the hardware.
That could be tricky. It's generally pretty hard to do that kind switch
between real and virtual CPU, because the virtual CPU has a lot more
state than the real one. I would assume, at least initially, that
running a kernel in this environment would have a very small
special-purpose user-mode component to exercise the kernel. Besides,
doing the whole system, you can trace how values from user-mode are
copied through the kernel and how they are used (taint checking, as well
as definedness checking).
> > Device memory look like it might be a bit tricky [...]
>
> This is something I'm interested in thinking about eventually. But one of
> the benefits of using Xen is that you can punt it for later. A very useful
> Xen guest OS can run without any kind of direct device access, just using
> the provided virtual disk and network devices.
Yep, good point.
> > Hm, exception handling will also be interesting to deal with. It will
> > definitely need precise exception state information from the VCPU.
>
> I don't know what issues you are anticipating here. The situation seems
> straightforward to me.
This is more a Valgrind issue. The current VCPU machinery does
everything at the basic-block level, and defers handling async signals
(interrupts) to between basic blocks; this works well, because the
virtual CPU state is well defined then. Within a basic blocks, the
state is not well defined, since the mapping of virtual registers to
real is non-deterministic (well, its deterministic, but nothing records
the mapping of virtual->real as a function of eip), so getting precise
machine state if an instruction faults is not possible. Mostly this
doesn't matter, since not many user-mode programs really care about the
precise machine state when dealing with a SIGSEGV. The kernel clearly
will.
But Julian is working on new VCPU machinery which will support recovery
of precise machine state at any point.
> > It will take a bit of work to adapt Valgrind to running in a (mostly)
> > unhosted environment.
>
> There are two different sets of issues to attack. One is valgrind as a Xen
> client, which has these issues. The other is valgrind as a Xen hypervisor
> implementation from the perspective of the guest OS running under
> translation. These are separable. After all, one could very well have
> valgrind run as a normal user program on whatever kind of host, and run a
> Xen guest OS binary purely through translation and internal bookkeeping
> implementing what the hypervisor interface claims are segments and page
> tables. I actually haven't decided at the moment whether that's just a
> rhetorical notion or might be a worthwhile prototyping direction to stave
> off coping with the actual hypervisor environment while implementing the
> virtual hypervisor interface support.
Yes, that's an interesting line of thought. Even without the Valgrind
component, user-mode Xen would subsume UML. Might get very expensive
emulating the paging hardware with mmap though.
> The hypervisor provides a general mechanism for guest domains to
> communicate, which is in fact what underlies the virtual devices. It might
> be most useful to do something special with this stuff directly, extending
> the control stuff that runs on the domain0 ("host" roughly) OS to provide
> valgrind log channels directly rather than kludging something with network
> packets. Anyway, details indeed.
Well, Valgrind already supports sending all its output through a socket,
and there's a long-standing wishlist item to produce more structured
output for programmatic consumption, so it might all come together
naturally.
There's also the question of getting input from the user (since Valgrind
will go interactive sometimes if you want), and attaching a debugger.
J
|
|
From: Roland M. <ro...@re...> - 2004-12-03 10:22:29
|
Let me preface this by saying that I know zilch about valgrind internals,
and also do not really have anything to do with Xen. I haven't usefully
worked on or even used it, though I have read some of its code and am
generally clueful about this sort of thing in the abstract. Mostly I'm
just someone who thought these two great tastes would taste great together.
Surely more intelligent comments about the details are to be had from
actual Xen developers than my baseless pontifications can provide.
From an implementation perspective, Xen is attractive exactly for the
reasons you cite, and that's a significant reason I suggested it. It
indeed does not allow guest OS code to use privileged instructions, and the
interface its hypercalls provide is substantially simpler to understand and
emulate thoroughly than is the x86 privileged hardware. At the same time,
part of the beauty of Xen is that it does so little--the arrangement is
sufficiently straightforward (from the perspective of understanding the
hardware features) that it seems that it may wind up presenting fewer
idiosyncratic implementation issues than UML does. Xen guest OS's are
already adapted to being in an environment that is not quite real but close
enough, so valgrind isn't adding new kinds of constraints.
> The main one is probably working out how to handle the page tables and
> segments. Need to look at this in more detail.
Page table issues and segmentation issues are really quite separate and I'd
prefer to address their details independently. The page table handling is
intertwined with the essential allocation tracking. This is I think where
the real meat is that determines what several of the other decisions might
mean. I would like to discuss this in detail before getting too mired in
the other areas of detail.
> Hm, will we need to understand multiple code segments?
In the general case, yes. In practice, not really. (And anyway, there
really isn't all that much to it.) The yes is because the Xen hypercall
interface is pretty free in what it lets a guest OS do with its segments.
Loading and using segment registers (including setting %cs with jumps and
such) are not privileged instructions. There is a hypercall interface to
load segment descriptor tables of the guest OS's choice. Separate code
segments can be used both directly in jumps, and in hypercall interface
when specifying trap handlers.
The not really is because in extant guest OS implementations anyone wants
to use (such as xen/linux), the kernel code that you want instrumented only
ever uses the single standard flat code segment.
> Valgrind will need to know a little bit about CPU privilege modes.
This is intertwined with code segments in the x86 world. In fact, for
practical purposes the only need there will be to support code segment
changes is when they are used to change privilege mode.
> It should only allow int $0x82 from ring 1. We'll need to emulate the
> syscall instructions too (or pretend they don't exist).
I'm not clear on where you're headed here. For at least the first crack
plan, you only want the kernel code itself (ring 1) to be instrumented, and
when instrumented code switches rings, that should bust you out of
valgrindland to run user mode normally on the hardware.
> Device memory look like it might be a bit tricky [...]
This is something I'm interested in thinking about eventually. But one of
the benefits of using Xen is that you can punt it for later. A very useful
Xen guest OS can run without any kind of direct device access, just using
the provided virtual disk and network devices.
> Hm, exception handling will also be interesting to deal with. It will
> definitely need precise exception state information from the VCPU.
I don't know what issues you are anticipating here. The situation seems
straightforward to me.
> It will take a bit of work to adapt Valgrind to running in a (mostly)
> unhosted environment.
There are two different sets of issues to attack. One is valgrind as a Xen
client, which has these issues. The other is valgrind as a Xen hypervisor
implementation from the perspective of the guest OS running under
translation. These are separable. After all, one could very well have
valgrind run as a normal user program on whatever kind of host, and run a
Xen guest OS binary purely through translation and internal bookkeeping
implementing what the hypervisor interface claims are segments and page
tables. I actually haven't decided at the moment whether that's just a
rhetorical notion or might be a worthwhile prototyping direction to stave
off coping with the actual hypervisor environment while implementing the
virtual hypervisor interface support.
> Lots of details to sort out, like how to get output from Valgrind.
The hypervisor provides a general mechanism for guest domains to
communicate, which is in fact what underlies the virtual devices. It might
be most useful to do something special with this stuff directly, extending
the control stuff that runs on the domain0 ("host" roughly) OS to provide
valgrind log channels directly rather than kludging something with network
packets. Anyway, details indeed.
> So, definitely interesting, doable, but non-trivial.
As it should be. :-) I would like to pursue it, at least as a thought
experiment for the moment. I think this is a very doable direction to
start in, and it can lead in some even more interesting places once it
starts to gel.
Thanks,
Roland
|
|
From: Jeremy F. <je...@go...> - 2004-12-03 04:24:52
|
[ Some background valgrind-developers: Xen is a hypervisor for allowing multiple virtual machines on one real machine. It requires kernels to be ported to its environment, but the benefit is that it has much higher performance than things like VMWare. Xen is GPLd, and available from http://www.cl.cam.ac.uk/netos/xen/ One nice aspect is that Xen doesn't allow guest OS's to run privileged instructions; instead they must use "hypercalls" to change privileged state, and thereby provide us with a nice hook to mediate these changes, and to avoid having to emulate the whole privileged side of the x86 architecture. ] Well, after a bit of a read of the Xen docs, I think I agree with you. I don't think there's any fundamental reason we couldn't adapt Valgrind to be a Xen guest kernel, and have it present a virtualized Xen interface to its own client. The Xen hypervisor call interface seems to have everything we'd need to get started. There are a few tricky points: The main one is probably working out how to handle the page tables and segments. Need to look at this in more detail. Hm, will we need to understand multiple code segments? Valgrind will need to know a little bit about CPU privilege modes. It should only allow int $0x82 from ring 1. We'll need to emulate the syscall instructions too (or pretend they don't exist). Device memory look like it might be a bit tricky, since we'd like to be able to do special things with reads and writes to it. In particular, it probably doesn't make sense to keep shadow memory for it; for memcheck we'd just assume that reads are all valid and writes need to be checked for validity. There isn't currently a good mechanism for doing this; Robert has his watchpoint patch, but it is surprisingly expensive, and we wouldn't need byte-level granularity. Hm, exception handling will also be interesting to deal with. It will definitely need precise exception state information from the VCPU. It is nice that Xen already makes it the guest OS's job to map between machine physical pages and virtual physical pages; it makes Valgrind's job much easier, since it can allocate memory anywhere. Hm, but having the machine->phys mapping readable at a fixed virtual address will make it tricky to virtualize. It will take a bit of work to adapt Valgrind to running in a (mostly) unhosted environment. Lots of details to sort out, like how to get output from Valgrind. (console_io would be a good first start, but I think a network connection is probably the best long-term solution.) Ironically, it might also be easier to get Valgrind to run on itself in this environment than in a normal Linux environment, because the "OS" layer is so much simpler, and therefore easier to completely virtualize. So, definitely interesting, doable, but non-trivial. J |
|
From: Jeremy F. <je...@go...> - 2004-12-03 04:12:35
|
On Thu, 2004-12-02 at 17:34 -0800, Roland McGrath wrote: > > > I guess that's probably about as useful as anyone needs. Or maybe > > > valgrind/xen. But I had contemplated actual normal native kernels with > > > built-in valgrind. > > > > Sounds interesting - what do you mean exactly though? > > I mean valgrind for a Linux kernel just like valgrind for a user process. > i.e., all the kernel code translated and monitored on the fly as it runs. > Only the valgrind engine itself really has to run normally, and a tiny bit > of glue for trap handlers to reenter valgrindland. The internal allocators > can have special hooks like normal valgrind's malloc does. I think this is > doable and it has appeal for hack value. But the more I think about, the > more it seems like the valgrinding xen is what is really the most useful > (and probably easier to do). i.e., a vanilla xen guest kernel can run > under a valgrind host instead of the real xen host. This would look like a new OS port for Valgrind, I guess, though it could get tricky. At the moment we don't emulate any privileged instructions, but I haven't read enough about Xen to know if that matters (do the Xen guest kernels run their own privileged instructions, or do they call into the hypervisor?). It would certainly be an interesting project from the perspective of making us be very clear about which parts of Valgrind are OS emulation and which parts are CPU emulation. I guess machine faults and traps are close enough to looking like signals to fit into the emulation model that way. The other interesting thing will be to work out how Valgrind can know about the various thread contexts within the kernel. This would relate to the thread-switch problem, and also so that we can use helgrind to examine the kernel's use of locking (which may or may not produce useful results). J |
|
From: <js...@ac...> - 2004-12-03 03:58:21
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2004-12-03 03:50:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) 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 ---------------------------------------- == 187 tests, 5 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_fcntl (stderr) memcheck/tests/scalar (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2004-12-03 03:25:39
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2004-12-03 03:20:03 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 192 tests, 12 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/badpoll (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_exit_group (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/writev (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-12-03 03:22:14
|
Nightly build on audi ( Red Hat 9 ) started at 2004-12-03 03:15:03 GMT 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 -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 192 tests, 12 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/badpoll (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_exit_group (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-12-03 03:11:37
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-12-03 03:10:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow Making check in x86-linux make[2]: Entering directory `/tmp/valgrind.25907/valgrind/coregrind/x86-linux' make[2]: Nothing to be done for `check'. make[2]: Leaving directory `/tmp/valgrind.25907/valgrind/coregrind/x86-linux' Making check in demangle make[2]: Entering directory `/tmp/valgrind.25907/valgrind/coregrind/demangle' make[2]: Nothing to be done for `check'. make[2]: Leaving directory `/tmp/valgrind.25907/valgrind/coregrind/demangle' Making check in . make[2]: Entering directory `/tmp/valgrind.25907/valgrind/coregrind' source='vg_to_ucode.c' object='stage2-vg_to_ucode.o' libtool=no \ depfile='.deps/stage2-vg_to_ucode.Po' tmpdepfile='.deps/stage2-vg_to_ucode.TPo' \ depmode=gcc3 /bin/sh ../depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I../coregrind -I../coregrind/x86 -I../coregrind/linux -I../coregrind/x86-linux -I../include -I../include -I../include/x86 -I../include/linux -I../include/x86-linux -DVG_LIBDIR="\"/tmp/valgrind.25907/valgrind/Inst/lib/valgrind"\" -I./demangle -DKICKSTART_BASE=0xb0000000 -DVG_PLATFORM="\"x86-linux"\" -Winline -Wall -Wshadow -O -g -fomit-frame-pointer -mpreferred-stack-boundary=2 -DELFSZ=32 -c -o stage2-vg_to_ucode.o `test -f 'vg_to_ucode.c' || echo './'`vg_to_ucode.c cc1: No space left on device: error writing to /tmp/cc93CBJf.s make[2]: *** [stage2-vg_to_ucode.o] Error 1 make[2]: Leaving directory `/tmp/valgrind.25907/valgrind/coregrind' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.25907/valgrind/coregrind' make: *** [check-recursive] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-12-03 03:08:34
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-12-03 03:05:02 GMT 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 rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) 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 ---------------------------------------- == 192 tests, 3 stderr failures, 1 stdout failure ================= memcheck/tests/scalar (stderr) memcheck/tests/vgtest_ume (stderr) none/tests/susphello (stdout) none/tests/susphello (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-12-03 03:04:12
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-12-03 03:00:02 GMT 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 rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) 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 ---------------------------------------- == 192 tests, 3 stderr failures, 1 stdout failure ================= memcheck/tests/scalar (stderr) memcheck/tests/vgtest_ume (stderr) none/tests/susphello (stdout) none/tests/susphello (stderr) make: *** [regtest] Error 1 |