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: John R. <jr...@bi...> - 2015-04-11 23:36:12
|
> On MIPS (ASUS RT-N16): > $ LD_SHOW_AUXV=1 /bin/true | grep AT_HWCAP > ### empty output from grep: no AT_HWCAP at all ... because the C library is uClibc, not glibc. Some digging shows that the AUX vector is: 0x00000010 AT_HWCAP 0x00000000 0x00000006 AT_PAGESZ 0x00001000 0x00000011 AT_CLKTCK 0x00000064 0x00000003 AT_PHDR 0x00400034 0x00000004 AT_PHENT 0x00000020 0x00000005 AT_PHNUM 0x00000008 0x00000007 AT_BASE 0x2aaa8000 0x00000008 AT_FLAGS 0x00000000 0x00000009 AT_ENTRY 0x00401740 0x0000000b AT_UID 0x00000000 0x0000000c AT_EUID 0x00000000 0x0000000d AT_GID 0x00000000 0x0000000e AT_EGID 0x00000000 0x00000017 AT_SECURE 0x00000000 0x00000000 AT_NULL 0x00000000 Still, AT_HWCAP is 0, which omits information such as support for mips16 and dsp that is shown in /proc/cpuinfo below. The Linux kernel is 2.6.24 (dd-wrt + optware.) > > $ cat /proc/cpuinfo ### abbreviated :) > system type : Broadcom BCM4716 chip rev 1 > cpu model : MIPS 74K V4.0 > ASEs implemented : mips16 dsp From the viewpoint of the end user, a commandline override such as --cpu=... has an advantage because it allows working around bugs in AT_HWCAP and/or /proc/cpuinfo. |
|
From: <sv...@va...> - 2015-04-11 18:50:54
|
Author: florian
Date: Sat Apr 11 19:50:47 2015
New Revision: 15085
Log:
Update list of ignored files.
Modified:
trunk/none/tests/ (props changed)
trunk/none/tests/tilegx/ (props changed)
|
|
From: <sv...@va...> - 2015-04-11 14:33:01
|
Author: philippe
Date: Sat Apr 11 15:32:53 2015
New Revision: 3125
Log:
VEX side for revision 15084 (multi arch testing)
Modified:
trunk/priv/host_arm64_isel.c
trunk/priv/host_mips_defs.c
trunk/pub/libvex_guest_amd64.h
Modified: trunk/priv/host_arm64_isel.c
==============================================================================
--- trunk/priv/host_arm64_isel.c (original)
+++ trunk/priv/host_arm64_isel.c Sat Apr 11 15:32:53 2015
@@ -3849,6 +3849,12 @@
case Ist_IMark:
return;
+ /* --------- ABI HINT --------- */
+ /* These have no meaning (denotation in the IR) and so we ignore
+ them ... if any actually made it this far. */
+ case Ist_AbiHint:
+ return;
+
/* --------- NO-OP --------- */
case Ist_NoOp:
return;
Modified: trunk/priv/host_mips_defs.c
==============================================================================
--- trunk/priv/host_mips_defs.c (original)
+++ trunk/priv/host_mips_defs.c Sat Apr 11 15:32:53 2015
@@ -2070,7 +2070,18 @@
*p++ = toUChar((w32 >> 8) & 0x000000FF);
*p++ = toUChar((w32 >> 16) & 0x000000FF);
*p++ = toUChar((w32 >> 24) & 0x000000FF);
-#elif defined (_MIPSEB)
+/* HACK !!!!
+ MIPS endianess is decided at compile time using gcc defined
+ symbols _MIPSEL or _MIPSEB. When compiling libvex in a cross-arch
+ setup, then none of these is defined. We just choose here by default
+ mips Big Endian to allow libvexmultiarch_test to work when using
+ a mips host architecture.
+ A cleaner way would be to either have mips using 'dynamic endness'
+ (like ppc64be or le, decided at runtime) or at least defining
+ by default _MIPSEB when compiling on a non mips system.
+#elif defined (_MIPSEB).
+*/
+#else
*p++ = toUChar((w32 >> 24) & 0x000000FF);
*p++ = toUChar((w32 >> 16) & 0x000000FF);
*p++ = toUChar((w32 >> 8) & 0x000000FF);
Modified: trunk/pub/libvex_guest_amd64.h
==============================================================================
--- trunk/pub/libvex_guest_amd64.h (original)
+++ trunk/pub/libvex_guest_amd64.h Sat Apr 11 15:32:53 2015
@@ -124,6 +124,7 @@
delicately-balanced PutI/GetI optimisation machinery.
Therefore best to leave it as a UInt. */
UInt guest_FTOP;
+ UInt pad1;
ULong guest_FPREG[8];
UChar guest_FPTAG[8];
ULong guest_FPROUND;
@@ -131,6 +132,7 @@
/* Emulation notes */
UInt guest_EMNOTE;
+ UInt pad2;
/* Translation-invalidation area description. Not used on amd64
(there is no invalidate-icache insn), but needed so as to
@@ -167,7 +169,7 @@
ULong guest_IP_AT_SYSCALL;
/* Padding to make it have an 16-aligned size */
- ULong pad1;
+ ULong pad3;
}
VexGuestAMD64State;
|
|
From: <sv...@va...> - 2015-04-11 11:42:31
|
Author: philippe
Date: Sat Apr 11 12:42:22 2015
New Revision: 15083
Log:
Remove useless arguments in sparsewa, that were inheritated from WordFM
These arguments are not needed for sparsewa, as they can only
return the key given in input.
Modified:
trunk/coregrind/m_sparsewa.c
trunk/helgrind/libhb_core.c
trunk/include/pub_tool_sparsewa.h
Modified: trunk/coregrind/m_sparsewa.c
==============================================================================
--- trunk/coregrind/m_sparsewa.c (original)
+++ trunk/coregrind/m_sparsewa.c Sat Apr 11 12:42:22 2015
@@ -274,7 +274,7 @@
Bool VG_(lookupSWA) ( const SparseWA* swa,
- /*OUT*/UWord* keyP, /*OUT*/UWord* valP,
+ /*OUT*/UWord* valP,
UWord key )
{
Int i;
@@ -302,7 +302,6 @@
vg_assert(level0->nInUse > 0);
ix = key & 0xFF;
if (swa_bitarray_read(level0->inUse, ix) == 0) return False;
- *keyP = key; /* this is stupid. only here to make it look like WordFM */
*valP = level0->words[ix];
return True;
}
@@ -366,7 +365,7 @@
Bool VG_(delFromSWA) ( SparseWA* swa,
- /*OUT*/UWord* oldK, /*OUT*/UWord* oldV, UWord key )
+ /*OUT*/UWord* oldV, UWord key )
{
Int i;
UWord ix;
@@ -403,7 +402,6 @@
if (swa_bitarray_read_then_clear(level0->inUse, ix) == 0)
return False;
- *oldK = key; /* this is silly */
*oldV = level0->words[ix];
level0->nInUse--;
Modified: trunk/helgrind/libhb_core.c
==============================================================================
--- trunk/helgrind/libhb_core.c (original)
+++ trunk/helgrind/libhb_core.c Sat Apr 11 12:42:22 2015
@@ -4149,7 +4149,7 @@
OldRef* ref;
RCEC* rcec;
Word i, j;
- UWord keyW, valW;
+ UWord valW;
Bool b;
tl_assert(thr);
@@ -4173,14 +4173,13 @@
/* Look in the map to see if we already have a record for this
address. */
- b = VG_(lookupSWA)( oldrefTree, &keyW, &valW, a );
+ b = VG_(lookupSWA)( oldrefTree, &valW, a );
if (b) {
/* We already have a record for this address. We now need to
see if we have a stack trace pertaining to this (thrid, R/W,
size) triple. */
- tl_assert(keyW == a);
ref = (OldRef*)valW;
tl_assert(ref->magic == OldRef_MAGIC);
@@ -4287,7 +4286,7 @@
{
Word i, j;
OldRef* ref;
- UWord keyW, valW;
+ UWord valW;
Bool b;
ThrID cand_thrid;
@@ -4319,12 +4318,11 @@
cand_a = toCheck[j];
// VG_(printf)("test %ld %p\n", j, cand_a);
- b = VG_(lookupSWA)( oldrefTree, &keyW, &valW, cand_a );
+ b = VG_(lookupSWA)( oldrefTree, &valW, cand_a );
if (!b)
continue;
ref = (OldRef*)valW;
- tl_assert(keyW == cand_a);
tl_assert(ref->magic == OldRef_MAGIC);
tl_assert(ref->accs[0].thrid != 0); /* first slot must always be used */
@@ -4705,9 +4703,8 @@
for (i = 0; i < n2del; i++) {
Bool b;
Addr ga2del = *(Addr*)VG_(indexXA)( refs2del, i );
- b = VG_(delFromSWA)( oldrefTree, &keyW, &valW, ga2del );
+ b = VG_(delFromSWA)( oldrefTree, &valW, ga2del );
tl_assert(b);
- tl_assert(keyW == ga2del);
oldref = (OldRef*)valW;
for (j = 0; j < N_OLDREF_ACCS; j++) {
ThrID aThrID = oldref->accs[j].thrid;
Modified: trunk/include/pub_tool_sparsewa.h
==============================================================================
--- trunk/include/pub_tool_sparsewa.h (original)
+++ trunk/include/pub_tool_sparsewa.h Sat Apr 11 12:42:22 2015
@@ -63,21 +63,17 @@
// overwritten. Returned Bool is True iff a previous binding existed.
Bool VG_(addToSWA) ( SparseWA* swa, UWord key, UWord val );
-// Delete key from swa, returning associated key and val if found.
-// Note: returning associated key is stupid (it can only be the
-// key you just specified). This behaviour is retained to make it
-// easier to migrate from WordFM. Returned Bool is True iff
-// the key was actually bound in the mapping.
+// Delete key from swa, returning val if found.
+// Returned Bool is True iff the key was actually bound in the mapping.
Bool VG_(delFromSWA) ( SparseWA* swa,
- /*OUT*/UWord* oldK, /*OUT*/UWord* oldV,
+ /*OUT*/UWord* oldV,
UWord key );
// Indexes swa at 'key' (or, if you like, looks up 'key' in the
-// mapping), and returns the associated value, if any, in *valP. For
-// compatibility with WordFM, 'key' is also returned in *keyP. Returned
-// Bool is True iff a binding for 'key' actually existed.
+// mapping), and returns the associated value, if any, in *valP.
+// Returned Bool is True iff a binding for 'key' actually existed.
Bool VG_(lookupSWA) ( const SparseWA* swa,
- /*OUT*/UWord* keyP, /*OUT*/UWord* valP,
+ /*OUT*/UWord* valP,
UWord key );
// Set up 'swa' for iteration.
|
|
From: Philippe W. <phi...@sk...> - 2015-04-11 11:29:14
|
On Sat, 2015-04-11 at 01:12 +0200, Philippe Waroquiers wrote:
> On Sat, 2015-04-11 at 01:02 +0200, Philippe Waroquiers wrote:
> > Julian,
> > do you agree that the offB_HOST_* offsets are depending on the host
> > architecture, and not on the guest architecture ?
> Moving the offB_HOST_* to the arch_host switch makes
> guest amd64/host tilegx
> work ok.
>
> It looks to me that this is the good thing to do
After an irc discussion with Julian, it became clear that this
is not the good thing to do, and that I misunderstood
the somewhat misleading names offB_HOST_EvC_COUNTER and
offB_HOST_EvC_FAILADDR.
Here is what I understand now:
These offB_HOST_* are really offset in the guest state,
which give locations in the guest state that are used by the
(generated) host code.
Basically, a translation entry (generated host code) is doing
if (-- guest_state->COUNTER) == 0) goto guest_state->FAILADDR
So, COUNTER and FAILADDR are in the guest state.
FAILADDR must be an host address
(this is in fact wrongly defined in all 32 bits guest states.
E.g. libvex_guest_x86.h and libvex_guest_ppc32.h defines
UInt host_EvC_FAILADDR;
while it should be the size of an host address (or at least
big enough to hold a 64 bit host address, if the host would
be 64 bits in a multiarch setup).
So, now I think the problem guest amd64/host tilegx
is better solved in the host tilegx code, that should ensure to always
generate the same nr of bytes for the evCheck instructions
(this was suggested by Zhigang)
(or maybe dynamically compute
the needed nr of instructions for an eventcheck, depending
on the offsets of the host_EvC_*, that changes the size of the
instructions).
Zhigang, does the above look reasonable to do in tilegx ?
(waiting for this to be done, I could always disable in the test
using tilegx as a host)
Thanks
Philippe
|
|
From: James D. <J.H...@ba...> - 2015-04-11 08:10:33
|
On Fri, 10 Apr 2015, Josef Weidendorfer <Jos...@gm...> wrote On Fri, 10 Apr 2015, Josef Weidendorfer <Jos...@gm...> wrote Subject: Re: [Valgrind-developers] Characteristics of VG simulated CPU My student Stavros Kaparelos (ska...@gm...) has a modification for Cachegrind that tracks L1/L2/L3 separately, and that also tracks TLB as well. James Davenport Am 10.04.2015 um 10:44 schrieb Alex: > Can someone provide a quick explanation what are the characteristics > of VG simulated CPU (cache, cores, core speed, threads)? Cachegrind/Callgrind simulate one 2-level cache hierarchy with separate L1 data and L1 instuction caches, and unified L2. L1 and L2 are inclusive (not strict inclusive) with write-allocate and LRU replacement. Cache parameters (associativity/sizes) are taken per default from the CPU you run VG on. For newer Intel CPUs with L3, the real L3 parameters are used for the L2 in the cache model. As events, you get number of instructions executed (= fetched from L1), data read and written from/to L1, L1D/L1I and L2 misses. James Davenport National Teaching Fellow 2014 Hebron & Medlock Professor of Information Technology, University of Bath OpenMath Content Dictionary Editor Director of Studies EPSRC Doctoral Taught Course Centre for HPC Chair, IMU Committee on Electronic Information and Communication Vice-President and Academy Trustee, British Computer Society SW Coordinator, Computing at School Network of Excellence |
|
From: Zhigang L. <zl...@ez...> - 2015-04-11 05:10:51
|
You are right, I will add them. ZhiGang ________________________________________ From: Philippe Waroquiers <phi...@sk...> Sent: Friday, April 10, 2015 7:39 PM To: Valgrind Developers Subject: [Valgrind-developers] TileGX : gdbserver xml files missing ? I see that valgrind-low-tilegx.c references the files tilegx-linux-valgrind.xml and tilegx-linux.xml (see target_xml function) but these files are not present in coregrind/m_gdbserver directory and are not in the GDBSERVER_XML_FILES in coregrind/Makefile.am I guess these files were missing in the patch ? Philippe ------------------------------------------------------------------------------ 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: Petar J. <mip...@gm...> - 2015-04-11 02:37:27
|
> * /tmp/ccpgn2sW.s:3257: Error: opcode not supported on this processor: mips2 (mips2) `clo $t0,$t1'> /tmp/ccpgn2sW.s:3345: Error: opcode not supported on this processor: mips2 (mips2) `clz $t0,$t1'> /tmp/ccpgn2sW.s:8311: Error: opcode not supported on this processor: mips2 (mips2) `madd $t0,$t1'> I did a bit research on 'clo' (clear ones). It looks like it should besupported. I think I'm missing the correct arch specification to gcc.* @Rich The errors you see come from the fact that Debian GCC (and Debian MIPS in general) is still set to the ancient mips2 variant. If you want to configure Valgrind and the tests for your MIPS32 capable system, pass "CFLAGS=-mips32" (or -mips32r2 for more optimal Valgrind if you run on MIPS32r2 capable CPU/emulator) to your configure line. Regards, Petar On Sat, Apr 11, 2015 at 1:16 AM, Rich Coe <rc...@wi...> wrote: > On Fri, 10 Apr 2015 10:41:10 -0500 > Rich Coe <rc...@wi...> wrote: > > On Wed, 8 Apr 2015 08:35:09 -0500 > > Rich Coe <rc...@wi...> wrote: > > > 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. > > > > I worked on creating a mips and a ppc qemu installation. I started with > ppc > > because I know that platform better. > > I created a qemu installation for mips from > wget > http://ftp.de.debian.org/debian/dists/wheezy/main/installer-mipsel/current/images/malta/netboot/vmlinux-3.2.0-4-4kc-malta > wget > http://ftp.de.debian.org/debian/dists/wheezy/main/installer-mipsel/current/images/malta/netboot/initrd.gz > > by running: > qemu-system-mipsel -m 256 -hda deb-mips.qcow2 -kernel > vmlinux-3.2.0-4-4kc-malta -initrd initrd.gz -append "root=/dev/ram > console=ttyS0" -nographic > > I installed: gcc g++ make automake autoconf subversion > > I built valgrind with the following config parameters: > Maximum build arch: mips32 > Primary build arch: mips32 > Secondary build arch: > Build OS: linux > Primary build target: MIPS32_LINUX > Secondary build target: > Platform variant: vanilla > Primary -DVGPV string: -DVGPV_mips32_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 > > V builds ok. When I try to build the tests, it fails building MIPS32int.c > with many errors (with duplicates removed) like > /tmp/ccpgn2sW.s:3257: Error: opcode not supported on this processor: mips2 > (mips2) `clo $t0,$t1' > /tmp/ccpgn2sW.s:3345: Error: opcode not supported on this processor: mips2 > (mips2) `clz $t0,$t1' > /tmp/ccpgn2sW.s:8311: Error: opcode not supported on this processor: mips2 > (mips2) `madd $t0,$t1' > > I did a bit research on 'clo' (clear ones). It looks like it should be > supported. I think I'm missing the correct arch specification to gcc. > > Rich > > > ------------------------------------------------------------------------------ > 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: Petar J. <mip...@gm...> - 2015-04-11 02:22:48
|
@Julian *> due to lack of nightly test machines for some architectures, especially mips32/64 and ...* While it may not be important for this thread, there is actually a set of Valgrind nightly build slaves [1] for selected MIPS variants (MIPS32r1-LE, MIPS32r2-LE, MIPS64-LE, MIPS64-BE). The buildbot has been in place since 2012, but the results have not been sent to the Valgrind mailing list. If anyone wants to take a look now, note that the large number of reported failures today is related to r15060. Prior to that, we had a dozen failures in average. E.g. [2]. As of MIPS and QEMU, I suggest you to take QEMU Debian images from Imagination Debian repository [3]. QEMU itself can be taken from the trunk [4]. Last, I believe the situation with MIPS machines on GCC Farm will be sorted out soon. Regards, Petar [1] http://www.rt-rk.com/mips-buildbot/builders [2] http://www.rt-rk.com/mips-buildbot/builders/XLP316/builds/500/steps/shell_1/logs/stdio [3] http://mipsdebian.imgtec.com/ [4] http://wiki.qemu.org/Download On Tue, Apr 7, 2015 at 4:44 PM, 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 > |