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
(30) |
2
(8) |
3
(5) |
4
(5) |
|
5
(3) |
6
(9) |
7
(5) |
8
(14) |
9
(17) |
10
(27) |
11
(10) |
|
12
(6) |
13
(10) |
14
(7) |
15
(16) |
16
(9) |
17
(14) |
18
(8) |
|
19
(5) |
20
(13) |
21
(21) |
22
(13) |
23
(4) |
24
(1) |
25
(4) |
|
26
(2) |
27
(7) |
28
(4) |
29
(5) |
30
(12) |
|
|
|
From: <sv...@va...> - 2015-04-08 19:01:23
|
Author: florian
Date: Wed Apr 8 20:01:15 2015
New Revision: 15077
Log:
Assorted cleanups: remove magic constants and unneeded header file. Update
a few comments. Exit with code 127 in bash emulation mode when file was
not found.
Modified:
trunk/coregrind/m_ume/elf.c
trunk/coregrind/m_ume/macho.c
trunk/coregrind/m_ume/main.c
trunk/coregrind/m_ume/priv_ume.h
trunk/coregrind/m_ume/script.c
Modified: trunk/coregrind/m_ume/elf.c
==============================================================================
--- trunk/coregrind/m_ume/elf.c (original)
+++ trunk/coregrind/m_ume/elf.c Wed Apr 8 20:01:15 2015
@@ -244,7 +244,7 @@
return elfbrk;
}
-Bool VG_(match_ELF)(const void *hdr, Int len)
+Bool VG_(match_ELF)(const void *hdr, SizeT len)
{
const ESZ(Ehdr) *e = hdr;
return (len > sizeof(*e)) && VG_(memcmp)(&e->e_ident[0], ELFMAG, SELFMAG) == 0;
Modified: trunk/coregrind/m_ume/macho.c
==============================================================================
--- trunk/coregrind/m_ume/macho.c (original)
+++ trunk/coregrind/m_ume/macho.c Wed Apr 8 20:01:15 2015
@@ -813,7 +813,7 @@
}
-Bool VG_(match_macho)(const void *hdr, Int len)
+Bool VG_(match_macho)(const void *hdr, SizeT len)
{
const vki_uint32_t *magic = hdr;
Modified: trunk/coregrind/m_ume/main.c
==============================================================================
--- trunk/coregrind/m_ume/main.c (original)
+++ trunk/coregrind/m_ume/main.c Wed Apr 8 20:01:15 2015
@@ -46,7 +46,7 @@
typedef struct {
- Bool (*match_fn)(const void *hdr, Int len);
+ Bool (*match_fn)(const void *hdr, SizeT len);
Int (*load_fn)(Int fd, const HChar *name, ExeInfo *info);
} ExeHandler;
@@ -70,7 +70,7 @@
Int fd, ret, i;
SysRes res;
Char buf[4096];
- SizeT bufsz = 4096, fsz;
+ SizeT bufsz = sizeof buf, fsz;
Bool is_setuid = False;
// Check it's readable
@@ -132,8 +132,8 @@
// returns: 0 = success, non-0 is failure
//
// We can execute only binaries (ELF, etc) or scripts that begin with "#!".
-// (Not, for example, scripts that don't begin with "#!"; see the
-// VG_(do_exec)() invocation from m_main.c for how that's handled.)
+// (Not, for example, scripts that don't begin with "#!"; see
+// do_exec_shell_followup for how that's handled.)
Int VG_(do_exec_inner)(const HChar* exe, ExeInfo* info)
{
SysRes res;
@@ -241,10 +241,17 @@
} else if (0 != ret) {
// Something else went wrong. Try to make the error more specific,
// and then print a message and abort.
-
- // Was it a directory?
+ Int exit_code = 126; // 126 == NOEXEC (bash)
+
res = VG_(stat)(exe_name, &st);
- if (!sr_isError(res) && VKI_S_ISDIR(st.mode)) {
+
+ // Does the file exist ?
+ if (sr_isError(res) && sr_Err(res) == VKI_ENOENT) {
+ VG_(fmsg)("%s: %s\n", exe_name, VG_(strerror)(ret));
+ exit_code = 127; // 127 == NOTFOUND (bash)
+
+ // Was it a directory?
+ } else if (!sr_isError(res) && VKI_S_ISDIR(st.mode)) {
VG_(fmsg)("%s: is a directory\n", exe_name);
// Was it not executable?
@@ -260,9 +267,7 @@
} else {
VG_(fmsg)("%s: %s\n", exe_name, VG_(strerror)(ret));
}
- // 126 means NOEXEC; I think this is Posix, and that in some cases we
- // should be returning 127, meaning NOTFOUND. Oh well.
- VG_(exit)(126);
+ VG_(exit)(exit_code);
}
return ret;
}
@@ -270,8 +275,8 @@
// This emulates the kernel's exec(). If it fails, it then emulates the
// shell's handling of the situation.
-// See ume.h for an indication of which entries of 'info' are inputs, which
-// are outputs, and which are both.
+// See pub_core_ume.h for an indication of which entries of 'info' are
+// inputs, which are outputs, and which are both.
/* returns: 0 = success, non-0 is failure */
Int VG_(do_exec)(const HChar* exe_name, ExeInfo* info)
{
Modified: trunk/coregrind/m_ume/priv_ume.h
==============================================================================
--- trunk/coregrind/m_ume/priv_ume.h (original)
+++ trunk/coregrind/m_ume/priv_ume.h Wed Apr 8 20:01:15 2015
@@ -34,19 +34,19 @@
#include "pub_core_ume.h" // ExeInfo
-extern int VG_(do_exec_inner)(const HChar *exe, ExeInfo *info);
+extern Int VG_(do_exec_inner)(const HChar *exe, ExeInfo *info);
#if defined(VGO_linux)
-extern Bool VG_(match_ELF) ( const void *hdr, Int len );
+extern Bool VG_(match_ELF) ( const void *hdr, SizeT len );
extern Int VG_(load_ELF) ( Int fd, const HChar *name, ExeInfo *info );
#elif defined(VGO_darwin)
-extern Bool VG_(match_macho) ( const void *hdr, Int len );
+extern Bool VG_(match_macho) ( const void *hdr, SizeT len );
extern Int VG_(load_macho) ( Int fd, const HChar *name, ExeInfo *info );
#else
# error Unknown OS
#endif
-extern Bool VG_(match_script) ( const void *hdr, Int len );
+extern Bool VG_(match_script) ( const void *hdr, SizeT len );
extern Int VG_(load_script) ( Int fd, const HChar *name, ExeInfo *info );
Modified: trunk/coregrind/m_ume/script.c
==============================================================================
--- trunk/coregrind/m_ume/script.c (original)
+++ trunk/coregrind/m_ume/script.c Wed Apr 8 20:01:15 2015
@@ -35,14 +35,13 @@
#include "pub_core_libcassert.h" // VG_(exit), vg_assert
#include "pub_core_libcfile.h" // VG_(close) et al
#include "pub_core_libcprint.h"
-#include "pub_core_xarray.h"
-#include "pub_core_clientstate.h"
+#include "pub_core_clientstate.h" // VG_(args_the_exename)
#include "pub_core_mallocfree.h" // VG_(strdup)
#include "pub_core_ume.h" // self
#include "priv_ume.h"
-Bool VG_(match_script)(const void *hdr, Int len)
+Bool VG_(match_script)(const void *hdr, SizeT len)
{
const HChar* script = hdr;
const HChar* end = script + len;
@@ -80,7 +79,7 @@
Int VG_(load_script)(Int fd, const HChar* name, ExeInfo* info)
{
HChar hdr[4096];
- Int len = 4096;
+ Int len = sizeof hdr;
Int eol;
HChar* interp;
HChar* end;
@@ -101,7 +100,7 @@
end = hdr + len;
interp = hdr + 2;
- while (interp < end && VG_(isspace)(*interp))
+ while (interp < end && (*interp == ' ' || *interp == '\t'))
interp++;
vg_assert(*interp == '/'); /* absolute path only for interpreter */
|
|
From: Rich C. <rc...@wi...> - 2015-04-08 13:35:17
|
I followed the instructions on this page (or one like it) https://en.opensuse.org/HCL:Chroot At the time, I downloaded openSUSE-Factory-ARM-JeOS.armv7-rootfs.armv7l-1.12.1-Build172.2.tbz like this for the current version wget http://download.opensuse.org/ports/armv7hl/factory/images/openSUSE-Factory-ARM-JeOS.armv7-rootfs.armv7l-1.12.1-Build288.4.tbz mkdir rootfs tar xvjf *Build288.4.tbz -C rootfs I installed 'qemu-linux-user', another linux os probably has a different name for the package. The currently installed qemu is 2.1.0. I then used the script below to start a new dev shell. Once in the shell, the first time I had to install the compiler, tools, etc: zypper ref zypper up zypper in gcc make SDL-devel automake autoconf subversion For mips or ppc, without JeOS, there should be a way to mount a distribution dvd of linux and install another platform. I'd have to look into it. Rich ----- #! /bin/bash if [ ! -e "/proc/sys/fs/binfmt_misc/arm" ]; then /usr/sbin/qemu-binfmt-conf.sh fi echo "mounting procs" mount --bind /proc rootfs/proc mount --bind /sys rootfs/sys mount --bind /dev rootfs/dev mount --bind ../../../github/odroid rootfs/usr/local/src/odroid cp /etc/resolv.conf rootfs/etc/ echo "starting chroot " chroot rootfs echo "un-mounting procs" umount rootfs/usr/local/src/odroid umount rootfs/dev umount rootfs/sys umount rootfs/proc ----- On Wed, 08 Apr 2015 09:29:55 +0200 Julian Seward <js...@ac...> wrote: > On 08/04/15 04:49, Rich Coe wrote: > > I had a working arm qemu implementation installed. > > That's interesting. Can you send some details of which (arm) distro you > are running and on which qemu version? Did you have to do any special > hoop-jumping to get the distro installed? > > > > When I run 'make regtest', vg fails with out of memory. > > The first time I did this, I figured that the qemu emulation was causing > > the issue, so I didn't pursue it. Perhaps there's some simple solution > > for fixing the 'out-of-memory' error. The allocated bytes looks like > > an overflow. > > > + Valgrind's memory management: out of memory: > > + newSuperblock's request for 4194304 bytes failed. > > + 4142292992 bytes have already been allocated. > > + Valgrind cannot continue. Sorry. > > I agree, that definitely doesn't look good. It shouldn't have failed in > the first place unless you have very low memory available in the guest and > don't have swap enabled for it. > > J > -- Rich Coe rc...@wi... |
|
From: <sv...@va...> - 2015-04-08 12:20:17
|
Author: florian
Date: Wed Apr 8 13:20:04 2015
New Revision: 15076
Log:
Consolidate shell script testcases without interpreter.
Added:
trunk/none/tests/scripts/shell_nointerp1
- copied, changed from r15075, trunk/none/tests/scripts/shell_valid2
trunk/none/tests/scripts/shell_nointerp1.stderr.exp
- copied unchanged from r15075, trunk/none/tests/scripts/shell_valid2.stderr.exp
trunk/none/tests/scripts/shell_nointerp1.vgtest
- copied, changed from r15075, trunk/none/tests/scripts/shell_valid2.vgtest
trunk/none/tests/scripts/shell_nointerp2 (with props)
trunk/none/tests/scripts/shell_nointerp2.stderr.exp
trunk/none/tests/scripts/shell_nointerp2.stdout.exp
trunk/none/tests/scripts/shell_nointerp2.vgtest
trunk/none/tests/scripts/shell_nointerp3 (with props)
trunk/none/tests/scripts/shell_nointerp3.stderr.exp
trunk/none/tests/scripts/shell_nointerp3.stdout.exp
trunk/none/tests/scripts/shell_nointerp3.vgtest
Removed:
trunk/none/tests/scripts/shell_valid2
trunk/none/tests/scripts/shell_valid2.stderr.exp
trunk/none/tests/scripts/shell_valid2.vgtest
trunk/none/tests/scripts/shell_valid3
trunk/none/tests/scripts/shell_valid3.stderr.exp
trunk/none/tests/scripts/shell_valid3.vgtest
Modified:
trunk/none/tests/scripts/Makefile.am
trunk/none/tests/scripts/shell
trunk/none/tests/scripts/shell.stdout.exp
Modified: trunk/none/tests/scripts/Makefile.am
==============================================================================
--- trunk/none/tests/scripts/Makefile.am (original)
+++ trunk/none/tests/scripts/Makefile.am Wed Apr 8 13:20:04 2015
@@ -13,11 +13,15 @@
shell_badinterp shell_badinterp.vgtest shell_badinterp.stderr.exp \
shell_binaryfile shell_binaryfile.vgtest shell_binaryfile.stderr.exp \
shell_dir.vgtest shell_dir.stderr.exp \
+ shell_nointerp1 shell_nointerp1.vgtest shell_nointerp1.stderr.exp \
+ shell_nointerp1.stdout.exp \
+ shell_nointerp2 shell_nointerp2.vgtest shell_nointerp2.stderr.exp \
+ shell_nointerp2.stdout.exp \
+ shell_nointerp3 shell_nointerp3.vgtest shell_nointerp3.stderr.exp \
+ shell_nointerp3.stdout.exp \
shell_nonexec.vgtest shell_nonexec.stderr.exp \
shell_nosuchfile.vgtest shell_nosuchfile.stderr.exp \
shell_valid1 shell_valid1.vgtest shell_valid1.stderr.exp \
- shell_valid2 shell_valid2.vgtest shell_valid2.stderr.exp \
- shell_valid3 shell_valid3.vgtest shell_valid3.stderr.exp \
shell_valid4 shell_valid4.vgtest shell_valid4.stderr.exp \
shell_valid4.stdout.exp \
shell_zerolength shell_zerolength.vgtest shell_zerolength.stderr.exp \
Modified: trunk/none/tests/scripts/shell
==============================================================================
--- trunk/none/tests/scripts/shell (original)
+++ trunk/none/tests/scripts/shell Wed Apr 8 13:20:04 2015
@@ -31,10 +31,10 @@
./shell_valid1
echo "Execute a valid script without a #! line"
-./shell_valid2
+./shell_nointerp1
echo "Execute a valid script with #! but no interpname"
-./shell_valid3
+./shell_nointerp2
echo "Execute a zero-length file"
./shell_zerolength
Modified: trunk/none/tests/scripts/shell.stdout.exp
==============================================================================
--- trunk/none/tests/scripts/shell.stdout.exp (original)
+++ trunk/none/tests/scripts/shell.stdout.exp Wed Apr 8 13:20:04 2015
@@ -6,5 +6,7 @@
Execute a non-existent file (2)
Execute a valid script with a #! line
Execute a valid script without a #! line
+tata
Execute a valid script with #! but no interpname
+no space after #!
Execute a zero-length file
Copied: trunk/none/tests/scripts/shell_nointerp1 (from r15075, trunk/none/tests/scripts/shell_valid2)
==============================================================================
--- trunk/none/tests/scripts/shell_valid2 (original)
+++ trunk/none/tests/scripts/shell_nointerp1 Wed Apr 8 13:20:04 2015
@@ -2,5 +2,5 @@
#
# This is a valid script without a #! line
-true
+echo tata
Copied: trunk/none/tests/scripts/shell_nointerp1.vgtest (from r15075, trunk/none/tests/scripts/shell_valid2.vgtest)
==============================================================================
--- trunk/none/tests/scripts/shell_valid2.vgtest (original)
+++ trunk/none/tests/scripts/shell_nointerp1.vgtest Wed Apr 8 13:20:04 2015
@@ -1,2 +1,2 @@
-prog: shell_valid2
+prog: shell_nointerp1
vgopts: -q
Added: trunk/none/tests/scripts/shell_nointerp2
==============================================================================
--- trunk/none/tests/scripts/shell_nointerp2 (added)
+++ trunk/none/tests/scripts/shell_nointerp2 Wed Apr 8 13:20:04 2015
@@ -0,0 +1,2 @@
+#!
+echo 'no space after #!'
Added: trunk/none/tests/scripts/shell_nointerp2.stderr.exp
==============================================================================
(empty)
Added: trunk/none/tests/scripts/shell_nointerp2.stdout.exp
==============================================================================
--- trunk/none/tests/scripts/shell_nointerp2.stdout.exp (added)
+++ trunk/none/tests/scripts/shell_nointerp2.stdout.exp Wed Apr 8 13:20:04 2015
@@ -0,0 +1 @@
+no space after #!
Added: trunk/none/tests/scripts/shell_nointerp2.vgtest
==============================================================================
--- trunk/none/tests/scripts/shell_nointerp2.vgtest (added)
+++ trunk/none/tests/scripts/shell_nointerp2.vgtest Wed Apr 8 13:20:04 2015
@@ -0,0 +1,2 @@
+prog: shell_nointerp2
+vgopts: -q
Added: trunk/none/tests/scripts/shell_nointerp3
==============================================================================
--- trunk/none/tests/scripts/shell_nointerp3 (added)
+++ trunk/none/tests/scripts/shell_nointerp3 Wed Apr 8 13:20:04 2015
@@ -0,0 +1,2 @@
+#!
+echo 'there is a space after the #!'
Added: trunk/none/tests/scripts/shell_nointerp3.stderr.exp
==============================================================================
(empty)
Added: trunk/none/tests/scripts/shell_nointerp3.stdout.exp
==============================================================================
--- trunk/none/tests/scripts/shell_nointerp3.stdout.exp (added)
+++ trunk/none/tests/scripts/shell_nointerp3.stdout.exp Wed Apr 8 13:20:04 2015
@@ -0,0 +1 @@
+there is a space after the #!
Added: trunk/none/tests/scripts/shell_nointerp3.vgtest
==============================================================================
--- trunk/none/tests/scripts/shell_nointerp3.vgtest (added)
+++ trunk/none/tests/scripts/shell_nointerp3.vgtest Wed Apr 8 13:20:04 2015
@@ -0,0 +1,2 @@
+prog: shell_nointerp3
+vgopts: -q
Removed: trunk/none/tests/scripts/shell_valid2
==============================================================================
--- trunk/none/tests/scripts/shell_valid2 (original)
+++ trunk/none/tests/scripts/shell_valid2 (removed)
@@ -1,6 +0,0 @@
-#
-#
-# This is a valid script without a #! line
-
-true
-
Removed: trunk/none/tests/scripts/shell_valid2.stderr.exp
==============================================================================
(empty)
Removed: trunk/none/tests/scripts/shell_valid2.vgtest
==============================================================================
--- trunk/none/tests/scripts/shell_valid2.vgtest (original)
+++ trunk/none/tests/scripts/shell_valid2.vgtest (removed)
@@ -1,2 +0,0 @@
-prog: shell_valid2
-vgopts: -q
Removed: trunk/none/tests/scripts/shell_valid3
==============================================================================
--- trunk/none/tests/scripts/shell_valid3 (original)
+++ trunk/none/tests/scripts/shell_valid3 (removed)
@@ -1,5 +0,0 @@
-#!
-#
-# The interpreter name is missing in this file.
-
-true
Removed: trunk/none/tests/scripts/shell_valid3.stderr.exp
==============================================================================
(empty)
Removed: trunk/none/tests/scripts/shell_valid3.vgtest
==============================================================================
--- trunk/none/tests/scripts/shell_valid3.vgtest (original)
+++ trunk/none/tests/scripts/shell_valid3.vgtest (removed)
@@ -1,2 +0,0 @@
-prog: shell_valid3
-vgopts: -q
|
|
From: santosh <ys...@gm...> - 2015-04-08 10:24:10
|
On Sun, Apr 5, 2015 at 9:05 AM, John Reiser <jr...@bi...> wrote: >> I still get the error: disInstr(ppc): unhandled instruction: 0x10E40301 >> I thought Valgrind 3.10.1 has support for CPU: e500v2? NO? > > 0x10E40301 ==> "evldd r7,0(r4)". Developers are much more likely to recognize 'evldd' > than an instruction word in hex. > > It is customary to give some documented basis for "I thought ...". Sorry. > > Just a little bit of searching the bug list: > https://bugs.kde.org Product: valgrind Content: e500 > yields this report from 2010-10-28 (4.5 years ago), last updated 2013-04-02 (two years ago): > https://bugs.kde.org/show_bug.cgi?id=255494 > which links to this attachment from a run of valgrind-3.6.0: > https://bugs.kde.org/attachment.cgi?id=52939 Thank you for pointing me towards right place. > which contains: > ----- > disInstr(ppc): unhandled instruction: 0x10E40301 > primary 4(0x4), secondary 769(0x301) > ==19630== valgrind: Unrecognised instruction at address 0x4019510. > [[snip]] > ==19630== Process terminating with default action of signal 4 (SIGILL): dumping core > ==19630== Illegal opcode at address 0x4019510 > ==19630== at 0x4019510: memcpy (in /lib/ld-2.8.so) > ==19630== by 0x40021BF: _dl_start_final (in /lib/ld-2.8.so) > ==19630== by 0x40162C7: _start (in /lib/ld-2.8.so) > ----- > So that code for memcpy has an optimization to fetch at least 64 bits at a time > in some circumstances, instead of only 32 bits. > Evidently valgrind-3.10.1 still does not implement this instruction. > > Your best bet is to comment on bug 255494, requesting implementation. > You could help by supplying a list of missing opcodes which, > if implemented, would be sufficient for valgrind to handle all of memcpy. > Until then, avoid code that contains this optimization. Install > a more-generic version of /lib/ld-2.8.so that does not use > the specialized instructions. > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for all > things parallel software development, from weekly thought leadership blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Florian K. <fl...@ei...> - 2015-04-08 09:46:07
|
On 08.04.2015 11:15, Julian Seward wrote:
>
>> Isn't there also a correctness issue with the status quo? You might get
>> a false result by comparing a SysRes from a pipe call with a SysRes from
>> a non-pipe call.
>
> That is true, but that is not a mips-specific problem -- it applies to all
> targets. You need to know that two SysRess came from the same syscall
> before comparing them.
Oh, you are right. Is equality of sycall numbers ensured today when we
do an sr_EQ? I briefly looked at the code and the single use of sr_EQ is
in eq_SyscallStatus which again is called once. Perhaps system call
numbers in that context are guaranteed to be the same, but it is not
obvious to me.
Which then raises the question of whether the system call number should
be added to SysRes for all archs (and maintained properly) and taken
into consideration in sr_EQ.
Perhaps:
typedef
struct {
UWord _sysno;
UWord _val
#if defined(VGA_mips32) || defined(VGA_mips64)
Bool _valEx;
#endif
}
SysRes;
static inline Bool sr_EQ ( SysRes sr1, SysRes sr2 ) {
return sr1._sysno == sr2._sysno // <----<< new
&& sr1._val == sr2._val
&& sr1._isError == sr2._isError
#if defined(VGA_mips32) || defined(VGA_mips64)
&& (sr1._sysno != _NR_pipe || sr1._valEx == sr2._valEx)
#endif
;
}
Florian
|
|
From: Julian S. <js...@ac...> - 2015-04-08 09:15:53
|
On 08/04/15 11:05, Florian Krohm wrote: > The advantage of the Boolean field would be that it is architecture > neutral. Yes. If we did make such a change, I would prefer the Boolean version rather than embedding the syscall number. (eg, which isn't even a single number on Darwin). I'd also prefer to do it by removing _valEx from all the Linux targets except mips*-linux and having a mips-specific version that includes _valEx and the new bool. This avoids having fields with no meaning for non-mips targets, which IMO would be confusing. > Isn't there also a correctness issue with the status quo? You might get > a false result by comparing a SysRes from a pipe call with a SysRes from > a non-pipe call. That is true, but that is not a mips-specific problem -- it applies to all targets. You need to know that two SysRess came from the same syscall before comparing them. Part of the value of this discussion (I've now understood) is to more clearly define the semantics of SysRes that it so far has been. As well as fixing the problem. J |
|
From: Florian K. <fl...@ei...> - 2015-04-08 09:05:14
|
On 08.04.2015 09:52, Petar Jovanovic wrote: > In order to set that boolean field correctly, at each point in which we > create SysRes, we need to know for which system call SysRes was created. > Similar solution - that would likely require similar number of changes - > would be to have SysRes carry its system call number. The advantage of the Boolean field would be that it is architecture neutral. It simply would be set to True for all architectures other than mips. If we recorded the system call number more work would be required for other architectures (or something less intuitive such as setting a fake system call number). So I'm favouring the Boolean field as well. Isn't there also a correctness issue with the status quo? You might get a false result by comparing a SysRes from a pipe call with a SysRes from a non-pipe call. If I understand correctly, such a comparison should produce a "not-equal" result whereas today it could produce an "equal" result. Florian |
|
From: Julian S. <js...@ac...> - 2015-04-08 08:40:53
|
On 08/04/15 09:52, Petar Jovanovic wrote: > In order to set that boolean field correctly, at each point in which we > create SysRes, we need to know for which system call SysRes was created. > Similar solution - that would likely require similar number of changes - > would be to have SysRes carry its system call number. I agree. It may be however that there are not many places where we construct a SysRes. I'll have a look at it. The reason I favour this solution is that, until now, SysRes has been an object that holds the (non-memory) results of a syscall, and can answer the following questions: 1. Did the syscall fail and if so what are the error-code bits? 2. Did the syscall succeed and if so what are the result bits? 3. Are you the same as this other SysRes ? But with the mips-pipe problem, SysRes can no longer reliably answer (2) or (3), because we don't know whether _valEx is part of the result bits or not. Hence we basically break the interface to this type. FWIW, the Darwin version of SysRes already contains similar machinery so as to make (1) (2) and (3) work reliably. So I don't think it's a big problem to do something similar for mips. Are there any community machines still alive, that I can try this out on? J |
|
From: Petar J. <mip...@gm...> - 2015-04-08 07:52:24
|
In order to set that boolean field correctly, at each point in which we create SysRes, we need to know for which system call SysRes was created. Similar solution - that would likely require similar number of changes - would be to have SysRes carry its system call number. Petar On Wed, Apr 8, 2015 at 9:26 AM, Julian Seward <js...@ac...> wrote: > > What would happen if, for mips, we added to SysRes, a boolean field that > indicates whether or not _valEx contains a live value? It seems to me > that at the moment we have "unclean" semantics because we can't know, from > a SysRes in isolation, whether or not _valEx needs to be taken into > account. > > It sounds, from Petar's earlier mail, that forcing _valEx to always be zero > in cases where it doesn't carry a live value, breaks stuff. And that > doesn't really reflect the kernel interface's semantics anyway, since that > implicitly seems to require that a SysRes is interpreted in the context of > whether the syscall that created it is or isn't sys_pipe. Hence my > proposal > to encode that information (as a bool) inside SysRes itself. > > I agree it would be nice to get this fixed cleanly, on the whole. > > J > > On 08/04/15 04:40, Petar Jovanovic wrote: > > Hi Florian, > > > > I have just given a second look to this issue. > > It seems to me that if we want to make sure SysRes is always correctly > > initialized (i.e. to make sure _valEx and v1 in guest state are set to > zero > > for non-pipe calls or for unsuccessful pipe call, we need to modify > several > > spots for MIPS: > > > > - within VG_(do_syscall), after syscall is executed > > - ML_(do_syscall_for_client_WRK) in syscall-mips64-linux.S > > - putSyscallStatusIntoGuestState > > - hack around vki_ucontext and VG_UCONTEXT_SYSCALL_SYSRES > > > > And we would be doing it to satisfy condition sr_EQ introduced in r15060 > > that's used for assert only. Do you think it is worth adding these > changes > > and workarounds? If you believe so, I will make the necessary changes. > > > > Regards, > > Petar > > > > > > On Sat, Apr 4, 2015 at 5:15 AM, Petar Jovanovic <mip...@gm...> > wrote: > > > >> > >> On Fri, Apr 3, 2015 at 4:29 PM, Florian Krohm <fl...@ei...> > >> wrote: > >> > >>> Yes. But comparing _valEx makes sense when it has a deterministic value > >>> (i.e. after a pipe call). So not comparing the _valEx value at all does > >>> not sound right either. > >> > >> > >> I agree. > >> > >> > >>> How is this (for mips64): > >>> > >>> Index: coregrind/m_syscall.c > >>> =================================================================== > >>> --- coregrind/m_syscall.c (revision 15062) > >>> +++ coregrind/m_syscall.c (working copy) > >>> @@ -859,6 +859,7 @@ > >>> ULong V0 = do_syscall_WRK(a1,a2,a3,a4,a5,a6,sysno,v1_a3); > >>> ULong V1 = (ULong)v1_a3[0]; > >>> ULong A3 = (ULong)v1_a3[1]; > >>> + if (sysno != _NR_pipe) V1 = 0; // V1 is unused for this syscall > >>> return VG_(mk_SysRes_mips64_linux)( V0, V1, A3 ); > >>> > >>> #else > >>> > >>> Does that help? > >>> > >>> > >> I have tested a similar change right away, but it was not sufficient. > >> I believe I need to modify at least putSyscallStatusIntoGuestState(), > >> will see if anything else is missing after more testing. > >> > >> Petar > >> > > > > > > > > > ------------------------------------------------------------------------------ > > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > > Develop your own process in accordance with the BPMN 2 standard > > Learn Process modeling best practices with Bonita BPM through live > exercises > > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- > event?utm_ > > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > > > > > > > > _______________________________________________ > > Valgrind-developers mailing list > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > > > |
|
From: Julian S. <js...@ac...> - 2015-04-08 07:30:08
|
On 08/04/15 04:49, Rich Coe wrote: > I had a working arm qemu implementation installed. That's interesting. Can you send some details of which (arm) distro you are running and on which qemu version? Did you have to do any special hoop-jumping to get the distro installed? > When I run 'make regtest', vg fails with out of memory. > The first time I did this, I figured that the qemu emulation was causing > the issue, so I didn't pursue it. Perhaps there's some simple solution > for fixing the 'out-of-memory' error. The allocated bytes looks like > an overflow. > + Valgrind's memory management: out of memory: > + newSuperblock's request for 4194304 bytes failed. > + 4142292992 bytes have already been allocated. > + Valgrind cannot continue. Sorry. I agree, that definitely doesn't look good. It shouldn't have failed in the first place unless you have very low memory available in the guest and don't have swap enabled for it. J |
|
From: Julian S. <js...@ac...> - 2015-04-08 07:26:54
|
What would happen if, for mips, we added to SysRes, a boolean field that indicates whether or not _valEx contains a live value? It seems to me that at the moment we have "unclean" semantics because we can't know, from a SysRes in isolation, whether or not _valEx needs to be taken into account. It sounds, from Petar's earlier mail, that forcing _valEx to always be zero in cases where it doesn't carry a live value, breaks stuff. And that doesn't really reflect the kernel interface's semantics anyway, since that implicitly seems to require that a SysRes is interpreted in the context of whether the syscall that created it is or isn't sys_pipe. Hence my proposal to encode that information (as a bool) inside SysRes itself. I agree it would be nice to get this fixed cleanly, on the whole. J On 08/04/15 04:40, Petar Jovanovic wrote: > Hi Florian, > > I have just given a second look to this issue. > It seems to me that if we want to make sure SysRes is always correctly > initialized (i.e. to make sure _valEx and v1 in guest state are set to zero > for non-pipe calls or for unsuccessful pipe call, we need to modify several > spots for MIPS: > > - within VG_(do_syscall), after syscall is executed > - ML_(do_syscall_for_client_WRK) in syscall-mips64-linux.S > - putSyscallStatusIntoGuestState > - hack around vki_ucontext and VG_UCONTEXT_SYSCALL_SYSRES > > And we would be doing it to satisfy condition sr_EQ introduced in r15060 > that's used for assert only. Do you think it is worth adding these changes > and workarounds? If you believe so, I will make the necessary changes. > > Regards, > Petar > > > On Sat, Apr 4, 2015 at 5:15 AM, Petar Jovanovic <mip...@gm...> wrote: > >> >> On Fri, Apr 3, 2015 at 4:29 PM, Florian Krohm <fl...@ei...> >> wrote: >> >>> Yes. But comparing _valEx makes sense when it has a deterministic value >>> (i.e. after a pipe call). So not comparing the _valEx value at all does >>> not sound right either. >> >> >> I agree. >> >> >>> How is this (for mips64): >>> >>> Index: coregrind/m_syscall.c >>> =================================================================== >>> --- coregrind/m_syscall.c (revision 15062) >>> +++ coregrind/m_syscall.c (working copy) >>> @@ -859,6 +859,7 @@ >>> ULong V0 = do_syscall_WRK(a1,a2,a3,a4,a5,a6,sysno,v1_a3); >>> ULong V1 = (ULong)v1_a3[0]; >>> ULong A3 = (ULong)v1_a3[1]; >>> + if (sysno != _NR_pipe) V1 = 0; // V1 is unused for this syscall >>> return VG_(mk_SysRes_mips64_linux)( V0, V1, A3 ); >>> >>> #else >>> >>> Does that help? >>> >>> >> I have tested a similar change right away, but it was not sufficient. >> I believe I need to modify at least putSyscallStatusIntoGuestState(), >> will see if anything else is missing after more testing. >> >> Petar >> > > > > ------------------------------------------------------------------------------ > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > > > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Julian S. <js...@ac...> - 2015-04-08 07:08:27
|
[Torbjörn's reply; I forgot that he can't post to this list without first subscribing.] -------- Forwarded Message -------- Subject: Re: Testing with QEMU and mips32/64, arm32/64 Date: Tue, 07 Apr 2015 18:04:00 +0200 From: tg...@gm... To: js...@ac... CC: Valgrind Developers <val...@li...> Julian Seward <js...@ac...> writes: Hi Torbjörn, Once again in Valgrind land we are having problems due to lack of nightly test machines for some architectures, especially mips32/64 and arm32/64. In the context of the conversation below, I seem to remember you said something to the effect that you use QEMU to solve this problem for GMP. Do I remember correctly? If so, do you have any information that you can share, regarding configurations of QEMU and Linux distros for these targets? I am wondering if we can set up QEMU VMs for at least some of them, so I am writing to ask if you know which QEMU+distro combinations work well enough to actually be useful. I maintain a page where all my successful (and some unsuccessful) installs are summarised, pl see <https://gmplib.org/~tege/qemu.html>. I've used mainly Debian until now. I'd be happy to help the Valgrind community to get this going. These are all full system emulation installs. The slowdown is often a problem, and multiplying QEMU's and Valgrind's slowdown might make things impractical. QEMU's mips64 slowdown factor for system emulation is around 80. I am migrating GMP testing to use user mode QEMU. A shell script installs by means of debootstrap all debian 6, 7, and 8 ports I have been able to make work. This uses the kernel feature 'binfmts' for transparently invoking QEMU. Not sure how well that'd conspire with Valgrind; I can envision some issues. (This script was not written for publication; I am willing to share it privately but I don't have time to clean it up for publication.) Recently somebody working for the present MIPS owner posted to the GMP list. Maybe he could help with a physical machine (or access to one): https://gmplib.org/list-archives/gmp-devel/2015-February/003933.html -- Torbjörn Please encrypt, key id 0xC8601622 |
|
From: Rich C. <rc...@wi...> - 2015-04-08 02:49:10
|
I had a working arm qemu implementation installed.
I had no difficulty building vg for the following platform:
Maximum build arch: arm
Primary build arch: arm
Secondary build arch:
Build OS: linux
Primary build target: ARM_LINUX
Secondary build target:
Platform variant: vanilla
Primary -DVGPV string: -DVGPV_arm_linux_vanilla=1
Default supp files: exp-sgcheck.supp xfree-3.supp xfree-4.supp glibc-2.X-drd.supp glibc-2.34567-NPTL-helgrind.supp glibc-2.X.supp
When I run 'make regtest', vg fails with out of memory.
The first time I did this, I figured that the qemu emulation was causing
the issue, so I didn't pursue it. Perhaps there's some simple solution
for fixing the 'out-of-memory' error. The allocated bytes looks like
an overflow.
--- allexec32.stderr.exp 2014-02-15 01:57:24.000000000 +0100
+++ allexec32.stderr.out 2015-04-08 02:30:27.000000000 +0200
@@ -1,14 +1,39 @@
+core : 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 4 rzB
+dinfo : 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 4 rzB
+(null) : 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 0 rzB
+demangle: 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 4 rzB
+ttaux : 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 4 rzB
+translate: no SP updates identified
+translate: PX: SPonly 0, UnwRegs 0, AllRegs 0, AllRegsAllInsns 0
+ tt/tc: 0 tt lookups requiring 0 probes
+ tt/tc: 0 fast-cache updates, 0 flushes
+ transtab: new 0 (0 -> 0; ratio 0.0) [0 scs] avg tce size 0
+ transtab: dumped 0 (0 -> ??) (sectors recycled 0)
+ transtab: discarded 0 (0 -> ??)
+scheduler: 0 event checks.
+scheduler: 0 indir transfers, 0 misses (1 in 0)
+scheduler: 0/0 major/minor sched events.
+ sanity: 0 cheap, 0 expensive checks.
+
+ Valgrind's memory management: out of memory:
+ newSuperblock's request for 4194304 bytes failed.
+ 4142292992 bytes have already been allocated.
+ Valgrind cannot continue. Sorry.
On Tue, 07 Apr 2015 16:44:24 +0200
Julian Seward <js...@ac...> wrote:
>
> Hi Torbjörn,
>
> Once again in Valgrind land we are having problems due to lack of
> nightly test machines for some architectures, especially mips32/64
> and arm32/64.
>
> In the context of the conversation below, I seem to remember you said
> something to the effect that you use QEMU to solve this problem for
> GMP. Do I remember correctly?
>
> If so, do you have any information that you can share, regarding
> configurations of QEMU and Linux distros for these targets? I am wondering
> if we can set up QEMU VMs for at least some of them, so I am writing to ask
> if you know which QEMU+distro combinations work well enough to actually be
> useful.
>
> Thanks,
>
> J
>
>
>
> -------- Forwarded Message --------
> Subject: Re: [Gcc-cfarm-users] Is there a mips(64)el box?
> Date: Fri, 10 Oct 2014 11:28:39 +0200
> From: Julian Seward <js...@ac...>
> Reply-To: js...@ac...
> To: Torbjörn Granlund <tg...@gm...>
> CC: Sergio Durigan Junior <ser...@re...>, gcc...@gn...,
> Philippe Waroquiers <phi...@sk...>
>
> On 10/10/2014 09:38 AM, Torbjörn Granlund wrote:
> > The only machines which are actually alive which are useful TO ME are
> > the two power7 machines. They allowed me to improve the performance of
> > my code for the chips, and let me do regular testing for ppc64 and AIX.
>
> The Power7 machine is also useful for Valgrind support. Without it it
> would be more difficult to maintain the ppc64 Valgrind port.
>
> There are (or were, at one time) a lot of machines in the farm, but most
> of them were x86 variants, which IMO are the least valuable because that
> hardware is most widely available. What the farm is really useful
> for is the more obscure stuff, viz, MIPS, PPC, ARM, which are harder to
> get hold of. For sure if there were fast, solid MIPS32/64 and AArch32/64
> machines, they would be useful for Valgrind testing and development.
>
> My impression is that it would be preferable to have fewer machines in
> the farm, but concentrate on providing at least one reliable, fast
> implementation of each of MIPS, PPC and ARM (32 and 64 bit in all
> cases). That is, to try and emphasise quality (breadth and reliability
> of supported targets) over quantity (numbers of machines).
>
> J
>
>
>
>
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
--
Rich Coe rc...@wi...
|
|
From: Petar J. <mip...@gm...> - 2015-04-08 02:40:32
|
Hi Florian, I have just given a second look to this issue. It seems to me that if we want to make sure SysRes is always correctly initialized (i.e. to make sure _valEx and v1 in guest state are set to zero for non-pipe calls or for unsuccessful pipe call, we need to modify several spots for MIPS: - within VG_(do_syscall), after syscall is executed - ML_(do_syscall_for_client_WRK) in syscall-mips64-linux.S - putSyscallStatusIntoGuestState - hack around vki_ucontext and VG_UCONTEXT_SYSCALL_SYSRES And we would be doing it to satisfy condition sr_EQ introduced in r15060 that's used for assert only. Do you think it is worth adding these changes and workarounds? If you believe so, I will make the necessary changes. Regards, Petar On Sat, Apr 4, 2015 at 5:15 AM, Petar Jovanovic <mip...@gm...> wrote: > > On Fri, Apr 3, 2015 at 4:29 PM, Florian Krohm <fl...@ei...> > wrote: > >> Yes. But comparing _valEx makes sense when it has a deterministic value >> (i.e. after a pipe call). So not comparing the _valEx value at all does >> not sound right either. > > > I agree. > > >> How is this (for mips64): >> >> Index: coregrind/m_syscall.c >> =================================================================== >> --- coregrind/m_syscall.c (revision 15062) >> +++ coregrind/m_syscall.c (working copy) >> @@ -859,6 +859,7 @@ >> ULong V0 = do_syscall_WRK(a1,a2,a3,a4,a5,a6,sysno,v1_a3); >> ULong V1 = (ULong)v1_a3[0]; >> ULong A3 = (ULong)v1_a3[1]; >> + if (sysno != _NR_pipe) V1 = 0; // V1 is unused for this syscall >> return VG_(mk_SysRes_mips64_linux)( V0, V1, A3 ); >> >> #else >> >> Does that help? >> >> > I have tested a similar change right away, but it was not sufficient. > I believe I need to modify at least putSyscallStatusIntoGuestState(), > will see if anything else is missing after more testing. > > Petar > |