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
(9) |
2
(7) |
3
(15) |
4
(14) |
|
5
(12) |
6
(18) |
7
(16) |
8
(13) |
9
(14) |
10
(20) |
11
(26) |
|
12
(14) |
13
(25) |
14
(20) |
15
(15) |
16
(14) |
17
(13) |
18
(12) |
|
19
(8) |
20
(16) |
21
(15) |
22
(37) |
23
(15) |
24
(18) |
25
(12) |
|
26
(8) |
27
(13) |
28
(12) |
|
|
|
|
|
From: Tom H. <to...@co...> - 2006-02-13 23:53:39
|
In message <43F...@wa...>
Eric Pouech <eri...@wa...> wrote:
> Tom Hughes wrote:
>
> > > I dunno (I do have the same thoughts about it). My point was not to make
> > > a 100% accurate patch, but at least to show the areas that needed to be
> > > improved. IMO, the best solution would be not to ask for a RT signal
> > > handler if the user doesn't ask for (there's nothing to be done here,
> > > just passing the information), but it complicates a bit the signal
> > > handling code on V side.
> >
> > I'm not sure I understand what you mean there - regardless of what
> > sort of handler valgrind asks the kernel for it should always be
> > presenting the right sort (rt or non-rt) of signal frame to the
> > application's handler.
>
> I was talking about the sig handler valgrinds asks for to the kernel.
> IMO, if we want to get the mappings 100% right from the kernel, we
> should do something like:
> - if the user asks for a non rt sig handler, vg should ask for a non rt
> sig handler
> - if the user asks for a rt sig handler, vg should ask for a rt sig handler
> of course, that would duplicate all the sig handler code
I understand what you are suggesting, but why do you think we need to
do it? and what does it have to do with the trap number stuff?
The rt handlers are effectvely a superset of the non-rt ones so we
can always construct a valid non-rt signal frame based on an rt
signal frames supplied to us by the kernel, which is what we do.
In other words it should be transparent to the application running
under valgrind that valgrind is always asking the kernel for rt
signal frames. You seem to think that it is not transparent for
some reason?
I think the correct solution to the trap number problem is to make
sure we propagate it from the original kernel delivered signal
frame to the one we create for the client program, but that is
slightly complicated. We would also need to fake something up when
we synthesise a signal.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Dave N. <dc...@us...> - 2006-02-13 20:41:36
|
Is there a set of standard test scenarios that you've run Valgrind under other than the regression test suite? IBM is interested in making sure that Valgrind on the IBM PPC platforms is as robust as possible so I was thinking that it would be worthwhile looking for other test applications, e.g. mozilla, mail programs, standard linux utilities (calculator, spreadsheet, editors). What applications of this sort have already been run on PPC? Do you have any expected results that I can compare against when running the same application on an IBM PPC platform? Are there other applications that have only been run on x86 that I might want to try? What might I expect in trying to assess whether or not valgrind is working as expected? Should I expect to have to create lots of suppressions to limit the volume of spurious/known errors from valgrind? Are most of the suppressions I'm going to want included in glibc-*.supp? Are there other suppression files for known problems for other applications? |
|
From: Dave N. <dc...@us...> - 2006-02-13 20:27:43
|
I have been asked to put together a 20-30 min. demo of Valgrind for users at IBM so that we can increase internal usage of the PPC Valgrind. I'm pretty new to valgrind so my knowledge of its capabilities is pretty much limited to what I've read in the documentation. I was wondering whether anyone has any suggestions or (notes from previous demos) of topics I should be sure to highlight. |
|
From: Eric P. <eri...@wa...> - 2006-02-13 20:25:22
|
Tom Hughes wrote: >>I dunno (I do have the same thoughts about it). My point was not to make >>a 100% accurate patch, but at least to show the areas that needed to be >>improved. IMO, the best solution would be not to ask for a RT signal >>handler if the user doesn't ask for (there's nothing to be done here, >>just passing the information), but it complicates a bit the signal >>handling code on V side. > > > I'm not sure I understand what you mean there - regardless of what > sort of handler valgrind asks the kernel for it should always be > presenting the right sort (rt or non-rt) of signal frame to the > application's handler. I was talking about the sig handler valgrinds asks for to the kernel. IMO, if we want to get the mappings 100% right from the kernel, we should do something like: - if the user asks for a non rt sig handler, vg should ask for a non rt sig handler - if the user asks for a rt sig handler, vg should ask for a rt sig handler of course, that would duplicate all the sig handler code A+ -- Eric Pouech |
|
From: <sv...@va...> - 2006-02-13 18:16:45
|
Author: sewardj
Date: 2006-02-13 18:16:41 +0000 (Mon, 13 Feb 2006)
New Revision: 5646
Log:
Fix boundary conditions relating to stack permissions (see r5645).
Modified:
trunk/coregrind/m_main.c
Modified: trunk/coregrind/m_main.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/m_main.c 2006-02-13 17:54:31 UTC (rev 5645)
+++ trunk/coregrind/m_main.c 2006-02-13 18:16:41 UTC (rev 5646)
@@ -2478,7 +2478,7 @@
required (VG_STACK_REDZONE_SZB). setup_client_stack() will
have allocated an extra page if a red zone is required, to be on=20
the safe side. */
- vg_assert(initial_client_SP-1 - VG_STACK_REDZONE_SZB > seg->start);
+ vg_assert(initial_client_SP - VG_STACK_REDZONE_SZB >=3D seg->start)=
;
VG_TRACK( die_mem_stack, seg->start, initial_client_SP=20
- VG_STACK_REDZONE_SZB - seg->=
start );
VG_(debugLog)(2, "main", "mark stack inaccessible %010lx-%010lx\n",
|
|
From: <sv...@va...> - 2006-02-13 17:54:42
|
Author: sewardj
Date: 2006-02-13 17:54:31 +0000 (Mon, 13 Feb 2006)
New Revision: 5645
Log:
When setting the initial permissions of the area below the initial
stack pointer, take into account any ABI-mandated red zone
(VG_STACK_REDZONE_SZB). This also requires ensuring that at least
that much extra space is available when laying out the stack, in
setup_client_stack().
Modified:
trunk/coregrind/m_main.c
Modified: trunk/coregrind/m_main.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/m_main.c 2006-02-13 14:23:05 UTC (rev 5644)
+++ trunk/coregrind/m_main.c 2006-02-13 17:54:31 UTC (rev 5645)
@@ -419,6 +419,24 @@
SizeT inner_HACK =3D 0;
Bool ok;
=20
+ /* So far we've only accounted for space requirements down to the
+ stack pointer. If this target's ABI requires a redzone below
+ the stack pointer, we need to allocate an extra page, to
+ handle the worst case in which the stack pointer is almost at
+ the bottom of a page, and so there is insufficient room left
+ over to put the redzone in. In this case the simple thing to
+ do is allocate an extra page, by shrinking the reservation by
+ one page and growing the anonymous area by a corresponding
+ page. */
+ vg_assert(VG_STACK_REDZONE_SZB >=3D 0);
+ vg_assert(VG_STACK_REDZONE_SZB < VKI_PAGE_SIZE);
+ if (VG_STACK_REDZONE_SZB > 0) {
+ vg_assert(resvn_size > VKI_PAGE_SIZE);
+ resvn_size -=3D VKI_PAGE_SIZE;
+ anon_start -=3D VKI_PAGE_SIZE;
+ anon_size +=3D VKI_PAGE_SIZE;
+ }
+
vg_assert(VG_IS_PAGE_ALIGNED(anon_size));
vg_assert(VG_IS_PAGE_ALIGNED(resvn_size));
vg_assert(VG_IS_PAGE_ALIGNED(anon_start));
@@ -2455,17 +2473,22 @@
vg_assert(initial_client_SP >=3D seg->start);
vg_assert(initial_client_SP <=3D seg->end);
=20
- /* Stuff below the initial SP is unaddressable. */
- /* NB: shouldn't this take into account the VG_STACK_REDZONE_SZB
- bytes below SP? */
- VG_TRACK( die_mem_stack, seg->start, initial_client_SP - seg->start=
);
+ /* Stuff below the initial SP is unaddressable. Take into
+ account any ABI-mandated space below the stack pointer that is
+ required (VG_STACK_REDZONE_SZB). setup_client_stack() will
+ have allocated an extra page if a red zone is required, to be on=20
+ the safe side. */
+ vg_assert(initial_client_SP-1 - VG_STACK_REDZONE_SZB > seg->start);
+ VG_TRACK( die_mem_stack, seg->start, initial_client_SP=20
+ - VG_STACK_REDZONE_SZB - seg->=
start );
VG_(debugLog)(2, "main", "mark stack inaccessible %010lx-%010lx\n",
- seg->start, initial_client_SP-1 );
+ seg->start, initial_client_SP-1 - VG_STACK_REDZONE=
_SZB);
=20
/* Also the assembly helpers. */
VG_TRACK( new_mem_startup,
(Addr)&VG_(trampoline_stuff_start),
- (Addr)&VG_(trampoline_stuff_end) - (Addr)&VG_(trampoline_=
stuff_start),
+ (Addr)&VG_(trampoline_stuff_end)=20
+ - (Addr)&VG_(trampoline_stuff_start),
False, /* readable? */
False, /* writable? */
True /* executable? */ );
|
|
From: Tom H. <to...@co...> - 2006-02-13 17:52:43
|
In message <43F...@wa...>
Eric Pouech <eri...@wa...> wrote:
> Tom Hughes wrote:
>
> > In message <43F...@wa...>
> > Eric Pouech <eri...@wa...> wrote:
> >
> > > 1/ trapno in sigframe (vg-trapno.diff)
> > > (already posted in the bug database, but enhanced from previous
> > > post). This patch sets the trapno field in sigframe structure.
> >
> > I did look at that bug yesterday but I'm not a big fan of your
> > solution and I'm trying to come up with a better approach.
> >
> > How accurate is the mapping you provided - given that you are trying
> > to go backwards from signal number/reason to trap number is that
> > actually a reversible mapping? or does the kernel map multiple trap
> > numbers to a single signal+reason combination in some cases?
>
> I dunno (I do have the same thoughts about it). My point was not to make
> a 100% accurate patch, but at least to show the areas that needed to be
> improved. IMO, the best solution would be not to ask for a RT signal
> handler if the user doesn't ask for (there's nothing to be done here,
> just passing the information), but it complicates a bit the signal
> handling code on V side.
I'm not sure I understand what you mean there - regardless of what
sort of handler valgrind asks the kernel for it should always be
presenting the right sort (rt or non-rt) of signal frame to the
application's handler.
> > > 3/ disabled support for tkill (vg-tkill.diff)
> > > This patch (partly) reenables tkill syscall under
> > > x86-linux. Basically, Wine is made to run either under (NPTL) pthread
> > > support, or old kernel thread support. We use tkill, which is
> > > transparent whatever the thread system we're running on (pthread or
> > > kthread).
> >
> > I think I've got your post in valgrind-users about this marked to
> > be looked at when I get a chance, but once again putting it on the
> > bug tracker is a better idea.
>
> Not sure I did post something to vg-users :-/
You're right, it was somebody else asking about tkill.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Eric P. <eri...@wa...> - 2006-02-13 17:37:05
|
Tom Hughes wrote: > In message <43F...@wa...> > Eric Pouech <eri...@wa...> wrote: > > >>1/ trapno in sigframe (vg-trapno.diff) >>(already posted in the bug database, but enhanced from previous >>post). This patch sets the trapno field in sigframe structure. > > > I did look at that bug yesterday but I'm not a big fan of your > solution and I'm trying to come up with a better approach. > > How accurate is the mapping you provided - given that you are trying > to go backwards from signal number/reason to trap number is that > actually a reversible mapping? or does the kernel map multiple trap > numbers to a single signal+reason combination in some cases? I dunno (I do have the same thoughts about it). My point was not to make a 100% accurate patch, but at least to show the areas that needed to be improved. IMO, the best solution would be not to ask for a RT signal handler if the user doesn't ask for (there's nothing to be done here, just passing the information), but it complicates a bit the signal handling code on V side. >>2/ handling ESP change in sig handler (vg-sig.diff) >>This patch tries to fetch the cases where a sig handler changes ESP in >>ucontext, and lets V know about it. Ok, it's a bit black magic, but it >>prevents a tons of warnings. I only wrote it for old signal frame >>signatures, but it's rather straightforward to implement it to RT >>signal handlers. > > > Can you put this on the bug tracker so we don't lose it please. Done >>3/ disabled support for tkill (vg-tkill.diff) >>This patch (partly) reenables tkill syscall under >>x86-linux. Basically, Wine is made to run either under (NPTL) pthread >>support, or old kernel thread support. We use tkill, which is >>transparent whatever the thread system we're running on (pthread or >>kthread). > > > I think I've got your post in valgrind-users about this marked to > be looked at when I get a chance, but once again putting it on the > bug tracker is a better idea. Not sure I did post something to vg-users :-/ Done for putting it on the bug tracker. > I will look at this, but I believe tkill is deprecated as it is > potentially dangerous and that tgkill is the preferred call now > where it is available as it ensures that you can only signal your > own threads. Yes, but it won't work on Linux < 2.6. So, we need to keep using tkill (at least on those kernels). I'll upgrade Wine to use tgkill on >= 2.6, that's a prefered solution. A+ -- Eric Pouech |
|
From: Cerion Armour-B. <ce...@op...> - 2006-02-13 14:50:35
|
On Monday 13 February 2006 15:06, Julian Seward wrote: > On Monday 13 February 2006 09:06, you wrote: > > On Monday 13 February 2006 06:14, Julian Seward wrote: > > ... > > > > > It occurred to me later that on ppc32 and 64, the stack pointer (r1) > > > is moved down just once at the start and back up at the end of the > > > procedure. (I think this is actually mandated by the ABI; I'm not sure > > > though). This means the number of stack changes that occur is > > > potentially much smaller than on x86, in which any function call > > > causes potentially many small stack changes as args are pushed. > > > > Unless odds things are done like vex does to calculate some intermediate > > value to be 'reinterpreted' using the stack, no? > > Well, I was talking about the simulated machine's stack here, not the > real one. Sure, we generate code that uses the stack to move stuff > between FP and integer regs etc from time to time, but that's done > on a different stack from which the client runs. (When running on > V, each thread has two stacks - one for V itself and one for the > simulated machine). > > J I understood that, but if the client does funny stuff like V does, or with self-hosting... C |
|
From: <sv...@va...> - 2006-02-13 14:23:12
|
Author: sewardj Date: 2006-02-13 14:23:05 +0000 (Mon, 13 Feb 2006) New Revision: 5644 Log: 'make dist' fix Modified: trunk/coregrind/Makefile.am Modified: trunk/coregrind/Makefile.am =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/Makefile.am 2006-02-13 05:15:27 UTC (rev 5643) +++ trunk/coregrind/Makefile.am 2006-02-13 14:23:05 UTC (rev 5644) @@ -111,6 +111,7 @@ vki_unistd.h \ vki_unistd-amd64-linux.h\ vki_unistd-ppc32-linux.h\ + vki_unistd-ppc64-linux.h\ vki_unistd-x86-linux.h \ m_coredump/priv_elf.h \ m_debuginfo/priv_symtab.h \ |
|
From: Julian S. <js...@ac...> - 2006-02-13 14:05:18
|
> > sure though). This means the number of stack changes that occur is > > potentially much smaller than on x86, in which any function call > > causes potentially many small stack changes as args are pushed. > > i know for sure that on x86 gcc *optimizes* function calls by doing one > sub and never pushing/popping anything. but why should this be part of > the abi? I don't know for sure, but I'd guess it makes life simpler for debuggers, stack unwinders and exception-throwers. J |
|
From: <js...@ac...> - 2006-02-13 11:52:15
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-02-13 05:00:01 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 192 tests, 11 stderr failures, 5 stdout failures ================= memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/stack_changes (stdout) memcheck/tests/stack_changes (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/mremap (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) |
|
From: Tom H. <to...@co...> - 2006-02-13 09:54:19
|
In message <43F...@wa...>
Eric Pouech <eri...@wa...> wrote:
> 1/ trapno in sigframe (vg-trapno.diff)
> (already posted in the bug database, but enhanced from previous
> post). This patch sets the trapno field in sigframe structure.
I did look at that bug yesterday but I'm not a big fan of your
solution and I'm trying to come up with a better approach.
How accurate is the mapping you provided - given that you are trying
to go backwards from signal number/reason to trap number is that
actually a reversible mapping? or does the kernel map multiple trap
numbers to a single signal+reason combination in some cases?
> 2/ handling ESP change in sig handler (vg-sig.diff)
> This patch tries to fetch the cases where a sig handler changes ESP in
> ucontext, and lets V know about it. Ok, it's a bit black magic, but it
> prevents a tons of warnings. I only wrote it for old signal frame
> signatures, but it's rather straightforward to implement it to RT
> signal handlers.
Can you put this on the bug tracker so we don't lose it please.
> 3/ disabled support for tkill (vg-tkill.diff)
> This patch (partly) reenables tkill syscall under
> x86-linux. Basically, Wine is made to run either under (NPTL) pthread
> support, or old kernel thread support. We use tkill, which is
> transparent whatever the thread system we're running on (pthread or
> kthread).
I think I've got your post in valgrind-users about this marked to
be looked at when I get a chance, but once again putting it on the
bug tracker is a better idea.
I will look at this, but I believe tkill is deprecated as it is
potentially dangerous and that tgkill is the preferred call now
where it is available as it ensures that you can only signal your
own threads.
> 4/ missing opcodes in X86 emulation (vg-vex.diff)
> Wine uses some implemented opcodes (push / pop of cs, ds, es, fs, and
> gs), as well as iret. The first ones were quite simple to
> implement. For iret, I put something together, which is wrong from
> emulation point of view:
> - eflags is not correctly restored, I simply copied the popf stuff
> - it doesn't restore cs
That's one for Julian.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Eric P. <eri...@wa...> - 2006-02-13 09:29:26
|
Julian Seward wrote: >>>When you say "valgrind fails", exactly what happens? >> >>==14133== Using valgrind-3.1.0, a dynamic binary instrumentation framework. > > > Ah. 3.1.0. That wasn't clear from before. Sure, I can repro the crash > with 3.1.0, but I guess something or other got fixed after 3.1.0, since > the program runs OK with the current trunk (pre 3.2.0) sources, as I said. > > So I suggest you dump 3.1.0 and check out and build the trunk, which is > very easy: see http://www.valgrind.org/downloads/repository.html > and let us know if you find any problems with that. with svn trunk things are way better ;-) But, not yet 100% correct. Basically, with the attached patches, Wine works (almost - see below) correctly, even for SEH: 1/ trapno in sigframe (vg-trapno.diff) (already posted in the bug database, but enhanced from previous post). This patch sets the trapno field in sigframe structure. 2/ handling ESP change in sig handler (vg-sig.diff) This patch tries to fetch the cases where a sig handler changes ESP in ucontext, and lets V know about it. Ok, it's a bit black magic, but it prevents a tons of warnings. I only wrote it for old signal frame signatures, but it's rather straightforward to implement it to RT signal handlers. 3/ disabled support for tkill (vg-tkill.diff) This patch (partly) reenables tkill syscall under x86-linux. Basically, Wine is made to run either under (NPTL) pthread support, or old kernel thread support. We use tkill, which is transparent whatever the thread system we're running on (pthread or kthread). 4/ missing opcodes in X86 emulation (vg-vex.diff) Wine uses some implemented opcodes (push / pop of cs, ds, es, fs, and gs), as well as iret. The first ones were quite simple to implement. For iret, I put something together, which is wrong from emulation point of view: - eflags is not correctly restored, I simply copied the popf stuff - it doesn't restore cs With those patches applied to V, I can now run simply SEH programs in Wine under memcheck. However, this still generates some warnings (invalid read/write of size 4), and for some of them are in code reading/writing values onto the stack, which looks like V is still fooled with all the tricks we do in Wine. Comments welcome! A+ -- Eric Pouech |
|
From: Oswald B. <os...@kd...> - 2006-02-13 07:24:17
|
On Mon, Feb 13, 2006 at 05:14:11AM +0000, Julian Seward wrote: > It occurred to me later that on ppc32 and 64, the stack pointer (r1) > is moved down just once at the start and back up at the end of the > procedure. (I think this is actually mandated by the ABI; I'm not > sure though). This means the number of stack changes that occur is > potentially much smaller than on x86, in which any function call > causes potentially many small stack changes as args are pushed. > i know for sure that on x86 gcc *optimizes* function calls by doing one sub and never pushing/popping anything. but why should this be part of the abi? -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
|
From: <sv...@va...> - 2006-02-13 05:15:31
|
Author: sewardj
Date: 2006-02-13 05:15:27 +0000 (Mon, 13 Feb 2006)
New Revision: 5643
Log:
Update Limitations section following recent ppc hackery.
Modified:
trunk/docs/xml/manual-core.xml
Modified: trunk/docs/xml/manual-core.xml
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/docs/xml/manual-core.xml 2006-02-12 18:56:16 UTC (rev 5642)
+++ trunk/docs/xml/manual-core.xml 2006-02-13 05:15:27 UTC (rev 5643)
@@ -1671,7 +1671,7 @@
programs actually work fine.</para>
=20
<para>Valgrind will run Linux ELF binaries, on a kernel 2.4.X or 2.6.X
-system, on the x86, amd64 and ppc32 architectures, subject to the
+system, on the x86, amd64, ppc32 and ppc64 architectures, subject to the
following constraints:</para>
=20
<itemizedlist>
@@ -1683,8 +1683,11 @@
Version 3.1.0 includes limited support for SSE3 on x86. This could
be improved if necessary.</para>
=20
- <para>On ppc32, almost all integer, floating point and Altivec
- instructions are supported.</para>
+ <para>On ppc32 and ppc64, almost all integer, floating point and Alti=
vec
+ instructions are supported. Specifically: integer and FP insns that =
are
+ mandatory for PowerPC, the "General-purpose optional" group (fsqrt, f=
sqrts,
+ stfiwx), the "Graphics optional" group (fre, fres, frsqrte, frsqrtes)=
, and
+ the Altivec (also known as VMX) SIMD instruction set, are supported.<=
/para>
</listitem>
=20
<listitem>
@@ -1745,7 +1748,7 @@
<listitem>
<para>As of version 3.0.0, Valgrind has the following limitations
in its implementation of x86/AMD64 floating point relative to=20
- the IEEE754 standard.</para>
+ IEEE754.</para>
=20
<para>Precision: There is no support for 80 bit arithmetic.
Internally, Valgrind represents all such "long double" numbers in 64
@@ -1804,7 +1807,8 @@
=20
<listitem>
<para>As of version 3.0.0, Valgrind has the following limitations in
- its implementation of x86/AMD64 SSE2 FP arithmetic.</para>
+ its implementation of x86/AMD64 SSE2 FP arithmetic, relative to=20
+ IEEE754.</para>
=20
<para>Essentially the same: no exceptions, and limited observance of
rounding mode. Also, SSE2 has control bits which make it treat
@@ -1815,21 +1819,36 @@
</listitem>
=20
<listitem>
- <para>As of version 3.1.0, Valgrind has the following limitations
- in its implementation of PPC32 FP arithmetic, both scalar and
- Altivec.</para>
+ <para>As of version 3.2.0, Valgrind has the following limitations
+ in its implementation of PPC32 and PPC64 floating point=20
+ arithmetic, relative to IEEE754.</para>
=20
- <para>Scalar: essentially as with x86/AMD64: no exceptions,=20
- and limited observance of rounding mode. For Altivec, FP arithmetic
+ <para>Scalar (non-Altivec): Valgrind provides a bit-exact emulation o=
f
+ all floating point instructions, except for "fre" and "fres", which a=
re
+ done more precisely than required by the PowerPC architecture specifi=
cation.
+ All floating point operations observe the current rounding mode.
+ </para>
+
+ <para>However, fpscr[FPRF] is not set after each operation. That cou=
ld
+ be done but would give measurable performance overheads, and so far
+ no need for it has been found.</para>
+
+ <para>As on x86/AMD64, IEEE754 exceptions are not supported: all floa=
ting
+ point exceptions are handled using the default IEEE fixup actions.
+ Valgrind detects, ignores, and can warn about, attempts to unmask=20
+ the 5 IEEE FP exception kinds by writing to the floating-point status=
=20
+ and control register (fpscr).
+ </para>
+
+ <para>Vector (Altivec, VMX): essentially as with x86/AMD64 SSE/SSE2:=20
+ no exceptions, and limited observance of rounding mode. =20
+ For Altivec, FP arithmetic
is done in IEEE/Java mode, which is more accurate than the Linux defa=
ult
setting. "More accurate" means that denormals are handled properly,=20
- rather than simply being flushed to zero.
- </para>
+ rather than simply being flushed to zero.</para>
</listitem>
-
</itemizedlist>
=20
-
<para>Programs which are known not to work are:</para>
<itemizedlist>
<listitem>
|
|
From: Julian S. <js...@ac...> - 2006-02-13 05:14:36
|
The 144 case certainly helped (2.6s -> 2.0s) on a program which is very call-intensive - nfib(30). The other 3 are also appear commonly in ppc64 code, but as you say did not make much improvement to the perf suite. I think fbench dropped about 5%. Considering that compvbits is going to be faster than the trunk at permissions-setting, this might be worth a reevaluation after that is merged, with the aim of getting rid of some or all of the 4 special cases I introduced. It occurred to me later that on ppc32 and 64, the stack pointer (r1) is moved down just once at the start and back up at the end of the procedure. (I think this is actually mandated by the ABI; I'm not sure though). This means the number of stack changes that occur is potentially much smaller than on x86, in which any function call causes potentially many small stack changes as args are pushed. In fact (thinking about it more) a similar thing probably happens on amd64: there is no ABI-mandated stack-pointer-moves-only-once requirement, but in practice the use of registers for almost all parameter passing probably leads to much the same effect. J On Monday 13 February 2006 03:26, Nicholas Nethercote wrote: > On Sun, 12 Feb 2006 sv...@va... wrote: > > Extend stack-permissions-change fast-case machinery to handle +/- 112, > > 128, 144 and 160. > > Did you time this to see if it actually made a difference? The benefit > from the fast stack handling is not that large. > > Nick > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: <js...@ac...> - 2006-02-13 03:57:25
|
Nightly build on g5 ( YDL 4.0, ppc970 ) started at 2006-02-13 04:40:00 CET Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 197 tests, 6 stderr failures, 1 stdout failure ================= memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) |
|
From: <js...@ac...> - 2006-02-13 03:56:59
|
Nightly build on phoenix ( SuSE 10.0 ) started at 2006-02-13 03:30:01 GMT 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 == 223 tests, 7 stderr failures, 0 stdout failures ================= memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <to...@co...> - 2006-02-13 03:43:49
|
Nightly build on dunsmere ( athlon, Fedora Core 4 ) started at 2006-02-13 03:30:06 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 225 tests, 8 stderr failures, 1 stdout failure ================= memcheck/tests/leak-tree (stderr) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2006-02-13 03:30:39
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-02-13 03:15:02 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 224 tests, 21 stderr failures, 1 stdout failure ================= memcheck/tests/addressable (stderr) memcheck/tests/badjump (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (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/mempool (stderr) memcheck/tests/partial_load_dflt (stderr) memcheck/tests/partial_load_ok (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) memcheck/tests/xml1 (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Nicholas N. <nj...@cs...> - 2006-02-13 03:27:09
|
On Sun, 12 Feb 2006 sv...@va... wrote: > Extend stack-permissions-change fast-case machinery to handle +/- 112, > 128, 144 and 160. Did you time this to see if it actually made a difference? The benefit from the fast stack handling is not that large. Nick |
|
From: Tom H. <th...@cy...> - 2006-02-13 03:21:37
|
Nightly build on dellow ( x86_64, Fedora Core 4 ) started at 2006-02-13 03:10:12 GMT
Results differ from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... failed
Regression test results follow
== 245 tests, 5 stderr failures, 1 stdout failure =================
memcheck/tests/x86/scalar (stderr)
memcheck/tests/x86/scalar_supp (stderr)
memcheck/tests/x86/sse1_memory (stdout)
none/tests/amd64/faultstatus (stderr)
none/tests/x86/faultstatus (stderr)
none/tests/x86/int (stderr)
=================================================
== Results from 24 hours ago ==
=================================================
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... failed
Last 20 lines of verbose log follow echo
then mv -f ".deps/libcoregrind_amd64_linux_a-replacemalloc_core.Tpo" ".deps/libcoregrind_amd64_linux_a-replacemalloc_core.Po"; else rm -f ".deps/libcoregrind_amd64_linux_a-replacemalloc_core.Tpo"; exit 1; fi
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVG_PLATFORM="\"amd64-linux\"" -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.6425/Inst/lib/valgrind"\" -m64 -fomit-frame-pointer -O -g -Wmissing-prototypes -Winline -Wall -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement -MT libcoregrind_amd64_linux_a-scheduler.o -MD -MP -MF ".deps/libcoregrind_amd64_linux_a-scheduler.Tpo" -c -o libcoregrind_amd64_linux_a-scheduler.o `test -f 'm_scheduler/scheduler.c' || echo './'`m_scheduler/scheduler.c; \
then mv -f ".deps/libcoregrind_amd64_linux_a-scheduler.Tpo" ".deps/libcoregrind_amd64_linux_a-scheduler.Po"; else rm -f ".deps/libcoregrind_amd64_linux_a-scheduler.Tpo"; exit 1; fi
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVG_PLATFORM="\"amd64-linux\"" -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.6425/Inst/lib/valgrind"\" -m64 -fomit-frame-pointer -O -g -Wmissing-prototypes -Winline -Wall -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement -MT libcoregrind_amd64_linux_a-sema.o -MD -MP -MF ".deps/libcoregrind_amd64_linux_a-sema.Tpo" -c -o libcoregrind_amd64_linux_a-sema.o `test -f 'm_scheduler/sema.c' || echo './'`m_scheduler/sema.c; \
then mv -f ".deps/libcoregrind_amd64_linux_a-sema.Tpo" ".deps/libcoregrind_amd64_linux_a-sema.Po"; else rm -f ".deps/libcoregrind_amd64_linux_a-sema.Tpo"; exit 1; fi
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVG_PLATFORM="\"amd64-linux\"" -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.6425/Inst/lib/valgrind"\" -m64 -fomit-frame-pointer -O -g -Wmissing-prototypes -Winline -Wall -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement -MT libcoregrind_amd64_linux_a-syswrap-generic.o -MD -MP -MF ".deps/libcoregrind_amd64_linux_a-syswrap-generic.Tpo" -c -o libcoregrind_amd64_linux_a-syswrap-generic.o `test -f 'm_syswrap/syswrap-generic.c' || echo './'`m_syswrap/syswrap-generic.c; \
then mv -f ".deps/libcoregrind_amd64_linux_a-syswrap-generic.Tpo" ".deps/libcoregrind_amd64_linux_a-syswrap-generic.Po"; else rm -f ".deps/libcoregrind_amd64_linux_a-syswrap-generic.Tpo"; exit 1; fi
m_syswrap/syswrap-generic.c: In function 'vgSysWrap_generic_sys_ioctl_before':
m_syswrap/syswrap-generic.c:3169: error: 'VKI_TIOCGICOUNT' undeclared (first use in this function)
m_syswrap/syswrap-generic.c:3169: error: (Each undeclared identifier is reported only once
m_syswrap/syswrap-generic.c:3169: error: for each function it appears in.)
m_syswrap/syswrap-generic.c: In function 'vgSysWrap_generic_sys_ioctl_after':
m_syswrap/syswrap-generic.c:3985: error: 'VKI_TIOCGICOUNT' undeclared (first use in this function)
make[3]: *** [libcoregrind_amd64_linux_a-syswrap-generic.o] Error 1
make[3]: Leaving directory `/tmp/valgrind.6425/valgrind/coregrind'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/tmp/valgrind.6425/valgrind/coregrind'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/valgrind.6425/valgrind'
make: *** [all] Error 2
=================================================
== Difference between 24 hours ago and now ==
=================================================
*** old.short Mon Feb 13 03:13:42 2006
--- new.short Mon Feb 13 03:21:31 2006
***************
*** 3,26 ****
Configuring valgrind ... done
! Building valgrind ... failed
- Last 20 lines of verbose log follow echo
- then mv -f ".deps/libcoregrind_amd64_linux_a-replacemalloc_core.Tpo" ".deps/libcoregrind_amd64_linux_a-replacemalloc_core.Po"; else rm -f ".deps/libcoregrind_amd64_linux_a-replacemalloc_core.Tpo"; exit 1; fi
- if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVG_PLATFORM="\"amd64-linux\"" -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.6425/Inst/lib/valgrind"\" -m64 -fomit-frame-pointer -O -g -Wmissing-prototypes -Winline -Wall -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement -MT libcoregrind_amd64_linux_a-scheduler.o -MD -MP -MF ".deps/libcoregrind_amd64_linux_a-scheduler.Tpo" -c -o libcoregrind_amd64_linux_a-scheduler.o `test -f 'm_scheduler/scheduler.c' || echo './'`m_scheduler/scheduler.c; \
- then mv -f ".deps/libcoregrind_amd64_linux_a-scheduler.Tpo" ".deps/libcoregrind_amd64_linux_a-scheduler.Po"; else rm -f ".deps/libcoregrind_amd64_linux_a-scheduler.Tpo"; exit 1; fi
- if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVG_PLATFORM="\"amd64-linux\"" -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.6425/Inst/lib/valgrind"\" -m64 -fomit-frame-pointer -O -g -Wmissing-prototypes -Winline -Wall -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement -MT libcoregrind_amd64_linux_a-sema.o -MD -MP -MF ".deps/libcoregrind_amd64_linux_a-sema.Tpo" -c -o libcoregrind_amd64_linux_a-sema.o `test -f 'm_scheduler/sema.c' || echo './'`m_scheduler/sema.c; \
- then mv -f ".deps/libcoregrind_amd64_linux_a-sema.Tpo" ".deps/libcoregrind_amd64_linux_a-sema.Po"; else rm -f ".deps/libcoregrind_amd64_linux_a-sema.Tpo"; exit 1; fi
- if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVG_PLATFORM="\"amd64-linux\"" -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.6425/Inst/lib/valgrind"\" -m64 -fomit-frame-pointer -O -g -Wmissing-prototypes -Winline -Wall -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement -MT libcoregrind_amd64_linux_a-syswrap-generic.o -MD -MP -MF ".deps/libcoregrind_amd64_linux_a-syswrap-generic.Tpo" -c -o libcoregrind_amd64_linux_a-syswrap-generic.o `test -f 'm_syswrap/syswrap-generic.c' || echo './'`m_syswrap/syswrap-generic.c; \
- then mv -f ".deps/libcoregrind_amd64_linux_a-syswrap-generic.Tpo" ".deps/libcoregrind_amd64_linux_a-syswrap-generic.Po"; else rm -f ".deps/libcoregrind_amd64_linux_a-syswrap-generic.Tpo"; exit 1; fi
- m_syswrap/syswrap-generic.c: In function 'vgSysWrap_generic_sys_ioctl_before':
- m_syswrap/syswrap-generic.c:3169: error: 'VKI_TIOCGICOUNT' undeclared (first use in this function)
- m_syswrap/syswrap-generic.c:3169: error: (Each undeclared identifier is reported only once
- m_syswrap/syswrap-generic.c:3169: error: for each function it appears in.)
- m_syswrap/syswrap-generic.c: In function 'vgSysWrap_generic_sys_ioctl_after':
- m_syswrap/syswrap-generic.c:3985: error: 'VKI_TIOCGICOUNT' undeclared (first use in this function)
- make[3]: *** [libcoregrind_amd64_linux_a-syswrap-generic.o] Error 1
- make[3]: Leaving directory `/tmp/valgrind.6425/valgrind/coregrind'
- make[2]: *** [all] Error 2
- make[2]: Leaving directory `/tmp/valgrind.6425/valgrind/coregrind'
- make[1]: *** [all-recursive] Error 1
- make[1]: Leaving directory `/tmp/valgrind.6425/valgrind'
- make: *** [all] Error 2
--- 3,16 ----
Configuring valgrind ... done
! Building valgrind ... done
! Running regression tests ... failed
!
! Regression test results follow
!
! == 245 tests, 5 stderr failures, 1 stdout failure =================
! memcheck/tests/x86/scalar (stderr)
! memcheck/tests/x86/scalar_supp (stderr)
! memcheck/tests/x86/sse1_memory (stdout)
! none/tests/amd64/faultstatus (stderr)
! none/tests/x86/faultstatus (stderr)
! none/tests/x86/int (stderr)
|
|
From: Tom H. <th...@cy...> - 2006-02-13 03:17:59
|
Nightly build on aston ( x86_64, Fedora Core 3 ) started at 2006-02-13 03:05:07 GMT
Results differ from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... failed
Regression test results follow
== 245 tests, 6 stderr failures, 1 stdout failure =================
memcheck/tests/stack_switch (stderr)
memcheck/tests/x86/scalar (stderr)
memcheck/tests/x86/scalar_supp (stderr)
memcheck/tests/x86/sse1_memory (stdout)
none/tests/amd64/faultstatus (stderr)
none/tests/x86/faultstatus (stderr)
none/tests/x86/int (stderr)
=================================================
== Results from 24 hours ago ==
=================================================
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... failed
Last 20 lines of verbose log follow echo
then mv -f ".deps/libcoregrind_amd64_linux_a-replacemalloc_core.Tpo" ".deps/libcoregrind_amd64_linux_a-replacemalloc_core.Po"; else rm -f ".deps/libcoregrind_amd64_linux_a-replacemalloc_core.Tpo"; exit 1; fi
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVG_PLATFORM="\"amd64-linux\"" -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.15621/Inst/lib/valgrind"\" -m64 -fomit-frame-pointer -O -g -Wmissing-prototypes -Winline -Wall -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-long-long -Wdeclaration-after-statement -MT libcoregrind_amd64_linux_a-scheduler.o -MD -MP -MF ".deps/libcoregrind_amd64_linux_a-scheduler.Tpo" -c -o libcoregrind_amd64_linux_a-scheduler.o `test -f 'm_scheduler/scheduler.c' || echo './'`m_scheduler/scheduler.c; \
then mv -f ".deps/libcoregrind_amd64_linux_a-scheduler.Tpo" ".deps/libcoregrind_amd64_linux_a-scheduler.Po"; else rm -f ".deps/libcoregrind_amd64_linux_a-scheduler.Tpo"; exit 1; fi
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVG_PLATFORM="\"amd64-linux\"" -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.15621/Inst/lib/valgrind"\" -m64 -fomit-frame-pointer -O -g -Wmissing-prototypes -Winline -Wall -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-long-long -Wdeclaration-after-statement -MT libcoregrind_amd64_linux_a-sema.o -MD -MP -MF ".deps/libcoregrind_amd64_linux_a-sema.Tpo" -c -o libcoregrind_amd64_linux_a-sema.o `test -f 'm_scheduler/sema.c' || echo './'`m_scheduler/sema.c; \
then mv -f ".deps/libcoregrind_amd64_linux_a-sema.Tpo" ".deps/libcoregrind_amd64_linux_a-sema.Po"; else rm -f ".deps/libcoregrind_amd64_linux_a-sema.Tpo"; exit 1; fi
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVG_PLATFORM="\"amd64-linux\"" -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.15621/Inst/lib/valgrind"\" -m64 -fomit-frame-pointer -O -g -Wmissing-prototypes -Winline -Wall -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-long-long -Wdeclaration-after-statement -MT libcoregrind_amd64_linux_a-syswrap-generic.o -MD -MP -MF ".deps/libcoregrind_amd64_linux_a-syswrap-generic.Tpo" -c -o libcoregrind_amd64_linux_a-syswrap-generic.o `test -f 'm_syswrap/syswrap-generic.c' || echo './'`m_syswrap/syswrap-generic.c; \
then mv -f ".deps/libcoregrind_amd64_linux_a-syswrap-generic.Tpo" ".deps/libcoregrind_amd64_linux_a-syswrap-generic.Po"; else rm -f ".deps/libcoregrind_amd64_linux_a-syswrap-generic.Tpo"; exit 1; fi
m_syswrap/syswrap-generic.c: In function `vgSysWrap_generic_sys_ioctl_before':
m_syswrap/syswrap-generic.c:3169: error: `VKI_TIOCGICOUNT' undeclared (first use in this function)
m_syswrap/syswrap-generic.c:3169: error: (Each undeclared identifier is reported only once
m_syswrap/syswrap-generic.c:3169: error: for each function it appears in.)
m_syswrap/syswrap-generic.c: In function `vgSysWrap_generic_sys_ioctl_after':
m_syswrap/syswrap-generic.c:3985: error: `VKI_TIOCGICOUNT' undeclared (first use in this function)
make[3]: *** [libcoregrind_amd64_linux_a-syswrap-generic.o] Error 1
make[3]: Leaving directory `/tmp/valgrind.15621/valgrind/coregrind'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/tmp/valgrind.15621/valgrind/coregrind'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/valgrind.15621/valgrind'
make: *** [all] Error 2
=================================================
== Difference between 24 hours ago and now ==
=================================================
*** old.short Mon Feb 13 03:09:42 2006
--- new.short Mon Feb 13 03:17:54 2006
***************
*** 3,26 ****
Configuring valgrind ... done
! Building valgrind ... failed
- Last 20 lines of verbose log follow echo
- then mv -f ".deps/libcoregrind_amd64_linux_a-replacemalloc_core.Tpo" ".deps/libcoregrind_amd64_linux_a-replacemalloc_core.Po"; else rm -f ".deps/libcoregrind_amd64_linux_a-replacemalloc_core.Tpo"; exit 1; fi
- if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVG_PLATFORM="\"amd64-linux\"" -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.15621/Inst/lib/valgrind"\" -m64 -fomit-frame-pointer -O -g -Wmissing-prototypes -Winline -Wall -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-long-long -Wdeclaration-after-statement -MT libcoregrind_amd64_linux_a-scheduler.o -MD -MP -MF ".deps/libcoregrind_amd64_linux_a-scheduler.Tpo" -c -o libcoregrind_amd64_linux_a-scheduler.o `test -f 'm_scheduler/scheduler.c' || echo './'`m_scheduler/scheduler.c; \
- then mv -f ".deps/libcoregrind_amd64_linux_a-scheduler.Tpo" ".deps/libcoregrind_amd64_linux_a-scheduler.Po"; else rm -f ".deps/libcoregrind_amd64_linux_a-scheduler.Tpo"; exit 1; fi
- if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVG_PLATFORM="\"amd64-linux\"" -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.15621/Inst/lib/valgrind"\" -m64 -fomit-frame-pointer -O -g -Wmissing-prototypes -Winline -Wall -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-long-long -Wdeclaration-after-statement -MT libcoregrind_amd64_linux_a-sema.o -MD -MP -MF ".deps/libcoregrind_amd64_linux_a-sema.Tpo" -c -o libcoregrind_amd64_linux_a-sema.o `test -f 'm_scheduler/sema.c' || echo './'`m_scheduler/sema.c; \
- then mv -f ".deps/libcoregrind_amd64_linux_a-sema.Tpo" ".deps/libcoregrind_amd64_linux_a-sema.Po"; else rm -f ".deps/libcoregrind_amd64_linux_a-sema.Tpo"; exit 1; fi
- if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVG_PLATFORM="\"amd64-linux\"" -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.15621/Inst/lib/valgrind"\" -m64 -fomit-frame-pointer -O -g -Wmissing-prototypes -Winline -Wall -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-long-long -Wdeclaration-after-statement -MT libcoregrind_amd64_linux_a-syswrap-generic.o -MD -MP -MF ".deps/libcoregrind_amd64_linux_a-syswrap-generic.Tpo" -c -o libcoregrind_amd64_linux_a-syswrap-generic.o `test -f 'm_syswrap/syswrap-generic.c' || echo './'`m_syswrap/syswrap-generic.c; \
- then mv -f ".deps/libcoregrind_amd64_linux_a-syswrap-generic.Tpo" ".deps/libcoregrind_amd64_linux_a-syswrap-generic.Po"; else rm -f ".deps/libcoregrind_amd64_linux_a-syswrap-generic.Tpo"; exit 1; fi
- m_syswrap/syswrap-generic.c: In function `vgSysWrap_generic_sys_ioctl_before':
- m_syswrap/syswrap-generic.c:3169: error: `VKI_TIOCGICOUNT' undeclared (first use in this function)
- m_syswrap/syswrap-generic.c:3169: error: (Each undeclared identifier is reported only once
- m_syswrap/syswrap-generic.c:3169: error: for each function it appears in.)
- m_syswrap/syswrap-generic.c: In function `vgSysWrap_generic_sys_ioctl_after':
- m_syswrap/syswrap-generic.c:3985: error: `VKI_TIOCGICOUNT' undeclared (first use in this function)
- make[3]: *** [libcoregrind_amd64_linux_a-syswrap-generic.o] Error 1
- make[3]: Leaving directory `/tmp/valgrind.15621/valgrind/coregrind'
- make[2]: *** [all] Error 2
- make[2]: Leaving directory `/tmp/valgrind.15621/valgrind/coregrind'
- make[1]: *** [all-recursive] Error 1
- make[1]: Leaving directory `/tmp/valgrind.15621/valgrind'
- make: *** [all] Error 2
--- 3,17 ----
Configuring valgrind ... done
! Building valgrind ... done
! Running regression tests ... failed
!
! Regression test results follow
!
! == 245 tests, 6 stderr failures, 1 stdout failure =================
! memcheck/tests/stack_switch (stderr)
! memcheck/tests/x86/scalar (stderr)
! memcheck/tests/x86/scalar_supp (stderr)
! memcheck/tests/x86/sse1_memory (stdout)
! none/tests/amd64/faultstatus (stderr)
! none/tests/x86/faultstatus (stderr)
! none/tests/x86/int (stderr)
|
|
From: Tom H. <th...@cy...> - 2006-02-13 03:12:19
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-02-13 03:00:04 GMT
Results differ from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... failed
Regression test results follow
== 245 tests, 7 stderr failures, 1 stdout failure =================
memcheck/tests/stack_switch (stderr)
memcheck/tests/x86/scalar (stderr)
memcheck/tests/x86/scalar_supp (stderr)
memcheck/tests/x86/sse1_memory (stdout)
none/tests/amd64/faultstatus (stderr)
none/tests/fdleak_fcntl (stderr)
none/tests/x86/faultstatus (stderr)
none/tests/x86/int (stderr)
=================================================
== Results from 24 hours ago ==
=================================================
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... failed
Last 20 lines of verbose log follow echo
then mv -f ".deps/libcoregrind_amd64_linux_a-replacemalloc_core.Tpo" ".deps/libcoregrind_amd64_linux_a-replacemalloc_core.Po"; else rm -f ".deps/libcoregrind_amd64_linux_a-replacemalloc_core.Tpo"; exit 1; fi
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVG_PLATFORM="\"amd64-linux\"" -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.31192/Inst/lib/valgrind"\" -m64 -fomit-frame-pointer -O -g -Wmissing-prototypes -Winline -Wall -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-long-long -Wdeclaration-after-statement -MT libcoregrind_amd64_linux_a-scheduler.o -MD -MP -MF ".deps/libcoregrind_amd64_linux_a-scheduler.Tpo" -c -o libcoregrind_amd64_linux_a-scheduler.o `test -f 'm_scheduler/scheduler.c' || echo './'`m_scheduler/scheduler.c; \
then mv -f ".deps/libcoregrind_amd64_linux_a-scheduler.Tpo" ".deps/libcoregrind_amd64_linux_a-scheduler.Po"; else rm -f ".deps/libcoregrind_amd64_linux_a-scheduler.Tpo"; exit 1; fi
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVG_PLATFORM="\"amd64-linux\"" -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.31192/Inst/lib/valgrind"\" -m64 -fomit-frame-pointer -O -g -Wmissing-prototypes -Winline -Wall -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-long-long -Wdeclaration-after-statement -MT libcoregrind_amd64_linux_a-sema.o -MD -MP -MF ".deps/libcoregrind_amd64_linux_a-sema.Tpo" -c -o libcoregrind_amd64_linux_a-sema.o `test -f 'm_scheduler/sema.c' || echo './'`m_scheduler/sema.c; \
then mv -f ".deps/libcoregrind_amd64_linux_a-sema.Tpo" ".deps/libcoregrind_amd64_linux_a-sema.Po"; else rm -f ".deps/libcoregrind_amd64_linux_a-sema.Tpo"; exit 1; fi
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVG_PLATFORM="\"amd64-linux\"" -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.31192/Inst/lib/valgrind"\" -m64 -fomit-frame-pointer -O -g -Wmissing-prototypes -Winline -Wall -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-long-long -Wdeclaration-after-statement -MT libcoregrind_amd64_linux_a-syswrap-generic.o -MD -MP -MF ".deps/libcoregrind_amd64_linux_a-syswrap-generic.Tpo" -c -o libcoregrind_amd64_linux_a-syswrap-generic.o `test -f 'm_syswrap/syswrap-generic.c' || echo './'`m_syswrap/syswrap-generic.c; \
then mv -f ".deps/libcoregrind_amd64_linux_a-syswrap-generic.Tpo" ".deps/libcoregrind_amd64_linux_a-syswrap-generic.Po"; else rm -f ".deps/libcoregrind_amd64_linux_a-syswrap-generic.Tpo"; exit 1; fi
m_syswrap/syswrap-generic.c: In function `vgSysWrap_generic_sys_ioctl_before':
m_syswrap/syswrap-generic.c:3169: error: `VKI_TIOCGICOUNT' undeclared (first use in this function)
m_syswrap/syswrap-generic.c:3169: error: (Each undeclared identifier is reported only once
m_syswrap/syswrap-generic.c:3169: error: for each function it appears in.)
m_syswrap/syswrap-generic.c: In function `vgSysWrap_generic_sys_ioctl_after':
m_syswrap/syswrap-generic.c:3985: error: `VKI_TIOCGICOUNT' undeclared (first use in this function)
make[3]: *** [libcoregrind_amd64_linux_a-syswrap-generic.o] Error 1
make[3]: Leaving directory `/tmp/valgrind.31192/valgrind/coregrind'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/tmp/valgrind.31192/valgrind/coregrind'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/valgrind.31192/valgrind'
make: *** [all] Error 2
=================================================
== Difference between 24 hours ago and now ==
=================================================
*** old.short Mon Feb 13 03:01:55 2006
--- new.short Mon Feb 13 03:12:11 2006
***************
*** 3,26 ****
Configuring valgrind ... done
! Building valgrind ... failed
- Last 20 lines of verbose log follow echo
- then mv -f ".deps/libcoregrind_amd64_linux_a-replacemalloc_core.Tpo" ".deps/libcoregrind_amd64_linux_a-replacemalloc_core.Po"; else rm -f ".deps/libcoregrind_amd64_linux_a-replacemalloc_core.Tpo"; exit 1; fi
- if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVG_PLATFORM="\"amd64-linux\"" -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.31192/Inst/lib/valgrind"\" -m64 -fomit-frame-pointer -O -g -Wmissing-prototypes -Winline -Wall -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-long-long -Wdeclaration-after-statement -MT libcoregrind_amd64_linux_a-scheduler.o -MD -MP -MF ".deps/libcoregrind_amd64_linux_a-scheduler.Tpo" -c -o libcoregrind_amd64_linux_a-scheduler.o `test -f 'm_scheduler/scheduler.c' || echo './'`m_scheduler/scheduler.c; \
- then mv -f ".deps/libcoregrind_amd64_linux_a-scheduler.Tpo" ".deps/libcoregrind_amd64_linux_a-scheduler.Po"; else rm -f ".deps/libcoregrind_amd64_linux_a-scheduler.Tpo"; exit 1; fi
- if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVG_PLATFORM="\"amd64-linux\"" -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.31192/Inst/lib/valgrind"\" -m64 -fomit-frame-pointer -O -g -Wmissing-prototypes -Winline -Wall -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-long-long -Wdeclaration-after-statement -MT libcoregrind_amd64_linux_a-sema.o -MD -MP -MF ".deps/libcoregrind_amd64_linux_a-sema.Tpo" -c -o libcoregrind_amd64_linux_a-sema.o `test -f 'm_scheduler/sema.c' || echo './'`m_scheduler/sema.c; \
- then mv -f ".deps/libcoregrind_amd64_linux_a-sema.Tpo" ".deps/libcoregrind_amd64_linux_a-sema.Po"; else rm -f ".deps/libcoregrind_amd64_linux_a-sema.Tpo"; exit 1; fi
- if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/amd64 -I../coregrind/linux -I../coregrind/amd64-linux -I../include -I../VEX/pub -DVG_PLATFORM="\"amd64-linux\"" -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -DVG_LIBDIR="\"/tmp/valgrind.31192/Inst/lib/valgrind"\" -m64 -fomit-frame-pointer -O -g -Wmissing-prototypes -Winline -Wall -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-long-long -Wdeclaration-after-statement -MT libcoregrind_amd64_linux_a-syswrap-generic.o -MD -MP -MF ".deps/libcoregrind_amd64_linux_a-syswrap-generic.Tpo" -c -o libcoregrind_amd64_linux_a-syswrap-generic.o `test -f 'm_syswrap/syswrap-generic.c' || echo './'`m_syswrap/syswrap-generic.c; \
- then mv -f ".deps/libcoregrind_amd64_linux_a-syswrap-generic.Tpo" ".deps/libcoregrind_amd64_linux_a-syswrap-generic.Po"; else rm -f ".deps/libcoregrind_amd64_linux_a-syswrap-generic.Tpo"; exit 1; fi
- m_syswrap/syswrap-generic.c: In function `vgSysWrap_generic_sys_ioctl_before':
- m_syswrap/syswrap-generic.c:3169: error: `VKI_TIOCGICOUNT' undeclared (first use in this function)
- m_syswrap/syswrap-generic.c:3169: error: (Each undeclared identifier is reported only once
- m_syswrap/syswrap-generic.c:3169: error: for each function it appears in.)
- m_syswrap/syswrap-generic.c: In function `vgSysWrap_generic_sys_ioctl_after':
- m_syswrap/syswrap-generic.c:3985: error: `VKI_TIOCGICOUNT' undeclared (first use in this function)
- make[3]: *** [libcoregrind_amd64_linux_a-syswrap-generic.o] Error 1
- make[3]: Leaving directory `/tmp/valgrind.31192/valgrind/coregrind'
- make[2]: *** [all] Error 2
- make[2]: Leaving directory `/tmp/valgrind.31192/valgrind/coregrind'
- make[1]: *** [all-recursive] Error 1
- make[1]: Leaving directory `/tmp/valgrind.31192/valgrind'
- make: *** [all] Error 2
--- 3,18 ----
Configuring valgrind ... done
! Building valgrind ... done
! Running regression tests ... failed
!
! Regression test results follow
!
! == 245 tests, 7 stderr failures, 1 stdout failure =================
! memcheck/tests/stack_switch (stderr)
! memcheck/tests/x86/scalar (stderr)
! memcheck/tests/x86/scalar_supp (stderr)
! memcheck/tests/x86/sse1_memory (stdout)
! none/tests/amd64/faultstatus (stderr)
! none/tests/fdleak_fcntl (stderr)
! none/tests/x86/faultstatus (stderr)
! none/tests/x86/int (stderr)
|