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-09 22:13:37
|
Author: philippe
Date: Thu Apr 9 23:13:29 2015
New Revision: 3123
Log:
Fix a typo in the example given in the comment
Modified:
trunk/priv/multiarch_main_main.c
Modified: trunk/priv/multiarch_main_main.c
==============================================================================
--- trunk/priv/multiarch_main_main.c (original)
+++ trunk/priv/multiarch_main_main.c Thu Apr 9 23:13:29 2015
@@ -56,7 +56,7 @@
-lvexmultiarch-amd64-linux *before* -lvex-amd64-linux
i.e;
gcc -o t1multi t1.o \
- -LInst/lib/valgrind -lvexmultiarch-x86-linux -lvex-amd64-linux -lgcc
+ -LInst/lib/valgrind -lvexmultiarch-amd64-linux -lvex-amd64-linux -lgcc
t1single will only be able to translate from amd64 to amd64.
t1multi will be able to translate from any arch supported by VEX
|
|
From: Zhigang L. <zl...@ez...> - 2015-04-09 20:40:48
|
Florian an all who concerns, I am in the middle to address your new comments, especially, the format issue of "guest_tilegx_toIR.c", which is based on a generated template file. I have to do it line by line to correct the format, I hope I could finish today, unless you think we could do it after the merge. This was the regression test result I had run with the patches last time. I could improve it further. About half of the failures are due to line # given by stack trace, the line # are within +/- 3 range compared to the expected. Apparently the stack trace code need some enhancement. We could do it later on. ----------------- == 539 tests, 21 stderr failures, 1 stdout failure, 1 stderrB failure, 3 stdoutB failures, 1 post failure == Thanks ZhiGang -----Original Message----- From: Florian Krohm [mailto:fl...@ei...] Sent: Thursday, April 09, 2015 12:47 PM To: js...@ac...; Valgrind Developers Cc: Zhigang Liu Subject: Re: [Valgrind-developers] Linux/TileGX port: last call for comments On 09.04.2015 15:48, Julian Seward wrote: > > Bug 339778 (https://bugs.kde.org/show_bug.cgi?id=339778) contains > patches for a port to TileGx, a 64 bit CPU. There has been quite some > reviewing and re-working of the patches. From my point of view they > are now ready to land. > > Are there any more comments or concerns regarding this bug? If so > please say so now. If not I propose to land it in the next day or so. This looks all pretty good to me. I added a few comments to the BZ. All minor stuff except the absence of insn tests. One thing I'd like to bring up is a nightly build with results posted to the mailing list. We already have enough ports without those and generally no idea how well those ports work and/or how they brake when new stuff gets added. We want to be able to observe that. Florian |
|
From: <sv...@va...> - 2015-04-09 20:07:18
|
Author: philippe
Date: Thu Apr 9 21:07:11 2015
New Revision: 15079
Log:
Add missing stdout.exp file
Added:
trunk/none/tests/scripts/shell_nointerp1.stdout.exp
Added: trunk/none/tests/scripts/shell_nointerp1.stdout.exp
==============================================================================
--- trunk/none/tests/scripts/shell_nointerp1.stdout.exp (added)
+++ trunk/none/tests/scripts/shell_nointerp1.stdout.exp Thu Apr 9 21:07:11 2015
@@ -0,0 +1 @@
+tata
|
|
From: Philippe W. <phi...@sk...> - 2015-04-09 20:06:08
|
On Thu, 2015-04-09 at 22:00 +0200, Florian Krohm wrote: > > * Not mandatory, but close: have an accessible machine by valgrind > > developers (in gcc compile farm or similarly accessible by valdev). > > > > For sure would be nice but probably not realistic. In most companies > granting external access to a machine would require an act of Congress > or something like that... Yes :). A maybe more realistic approach for such companies is to donate a machine to gcc compile farm (which also avoids the company the administration effort). Philippe |
|
From: Philippe W. <phi...@sk...> - 2015-04-09 20:03:07
|
On Thu, 2015-04-09 at 21:58 +0200, Florian Krohm wrote: > If you want to beat me at it feel free to do so :) This crashes in a very special case, no urgency :) Philippe |
|
From: Florian K. <fl...@ei...> - 2015-04-09 20:00:43
|
On 09.04.2015 21:11, Philippe Waroquiers wrote: > On Thu, 2015-04-09 at 18:46 +0200, Florian Krohm wrote: > >> One thing I'd like to bring up is a nightly build with results posted to >> the mailing list. We already have enough ports without those and >> generally no idea how well those ports work and/or how they brake when >> new stuff gets added. We want to be able to observe that. > > +1. > >>From my point of view, I would even say addition of a brand new OS > or brand new arch implies: > * Mandatory requirement: have a nightly build setup seconded! > * Not mandatory, but close: have an accessible machine by valgrind > developers (in gcc compile farm or similarly accessible by valdev). > For sure would be nice but probably not realistic. In most companies granting external access to a machine would require an act of Congress or something like that... Florian |
|
From: Florian K. <fl...@ei...> - 2015-04-09 19:59:03
|
On 09.04.2015 21:02, Philippe Waroquiers wrote: > On Thu, 2015-04-09 at 13:57 +0200, Julian Seward wrote: >> On 05/04/15 12:25, Ivo Raisr wrote: >>>> I think r15034 (changes adding VG_(am_is_bogus_client_stack_pointer)()) >>>> causes some form of regression in stack extending. >>>> ... >>>> >>> Bug report: >>> https://bugs.kde.org/show_bug.cgi?id=345887 >> >> Austin English (cc'd) was reporting recently, some strange segfault loop >> phenomenon which might possibly be related. Unfortunately not easily >> reproducible. 345887 should be pretty simple to track down, though. > We have already encountered some problems with detecting if/when > a stack can be extended. > I think VG_(am_is_bogus_client_stack_pointer)() name is somewhat > misleading, as this could return True for a fully valid client stack > pointer, but that is not in the 'extensible stack' but e.g. in a > non extensible pthread stack. > > We should rename it e.g. to > VG_(am_addr_is_in_extensible_stack_segment)() > or something like that. > > And then we have to be sure it is called before any call to > extend stack : after a quick look at 345887, we have at > least one missing place. I've seen it but won't have time to look at it this week. I'm away until Sunday. There are several places that are possibly missed. I think (not sure) the reason for the recent failure is that VG_(extend_stack) is not as permissive as it used to be. It believes pretty much that the passed in address is in a stack segment or in a neighbouring RESVN segment. That makes sense given the function name but.... If you want to beat me at it feel free to do so :) Florian > > 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: Philippe W. <phi...@sk...> - 2015-04-09 19:10:37
|
On Thu, 2015-04-09 at 18:46 +0200, Florian Krohm wrote: > One thing I'd like to bring up is a nightly build with results posted to > the mailing list. We already have enough ports without those and > generally no idea how well those ports work and/or how they brake when > new stuff gets added. We want to be able to observe that. +1. >From my point of view, I would even say addition of a brand new OS or brand new arch implies: * Mandatory requirement: have a nightly build setup * Not mandatory, but close: have an accessible machine by valgrind developers (in gcc compile farm or similarly accessible by valdev). Philippe |
|
From: Philippe W. <phi...@sk...> - 2015-04-09 19:02:09
|
On Thu, 2015-04-09 at 13:57 +0200, Julian Seward wrote: > On 05/04/15 12:25, Ivo Raisr wrote: > >> I think r15034 (changes adding VG_(am_is_bogus_client_stack_pointer)()) > >> causes some form of regression in stack extending. > >> ... > >> > > Bug report: > > https://bugs.kde.org/show_bug.cgi?id=345887 > > Austin English (cc'd) was reporting recently, some strange segfault loop > phenomenon which might possibly be related. Unfortunately not easily > reproducible. 345887 should be pretty simple to track down, though. We have already encountered some problems with detecting if/when a stack can be extended. I think VG_(am_is_bogus_client_stack_pointer)() name is somewhat misleading, as this could return True for a fully valid client stack pointer, but that is not in the 'extensible stack' but e.g. in a non extensible pthread stack. We should rename it e.g. to VG_(am_addr_is_in_extensible_stack_segment)() or something like that. And then we have to be sure it is called before any call to extend stack : after a quick look at 345887, we have at least one missing place. Philippe |
|
From: Roland M. <rol...@nr...> - 2015-04-09 16:55:27
|
On Thu, Apr 9, 2015 at 6:46 PM, Florian Krohm <fl...@ei...> wrote: > On 09.04.2015 15:48, Julian Seward wrote: >> >> Bug 339778 (https://bugs.kde.org/show_bug.cgi?id=339778) contains >> patches for a port to TileGx, a 64 bit CPU. There has been quite >> some reviewing and re-working of the patches. From my point of >> view they are now ready to land. >> >> Are there any more comments or concerns regarding this bug? If so >> please say so now. If not I propose to land it in the next day or so. > > This looks all pretty good to me. > I added a few comments to the BZ. All minor stuff except the absence of > insn tests. > > One thing I'd like to bring up is a nightly build with results posted to > the mailing list. We already have enough ports without those and > generally no idea how well those ports work and/or how they brake when > new stuff gets added. We want to be able to observe that. Is there any (free) emulator software for TileGX which could fill that testing gap somehow ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) rol...@nr... \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) |
|
From: Florian K. <fl...@ei...> - 2015-04-09 16:46:41
|
On 09.04.2015 15:48, Julian Seward wrote: > > Bug 339778 (https://bugs.kde.org/show_bug.cgi?id=339778) contains > patches for a port to TileGx, a 64 bit CPU. There has been quite > some reviewing and re-working of the patches. From my point of > view they are now ready to land. > > Are there any more comments or concerns regarding this bug? If so > please say so now. If not I propose to land it in the next day or so. This looks all pretty good to me. I added a few comments to the BZ. All minor stuff except the absence of insn tests. One thing I'd like to bring up is a nightly build with results posted to the mailing list. We already have enough ports without those and generally no idea how well those ports work and/or how they brake when new stuff gets added. We want to be able to observe that. Florian |
|
From: <sv...@va...> - 2015-04-09 16:23:28
|
Author: carll
Date: Thu Apr 9 17:23:20 2015
New Revision: 15078
Log:
ADD AT_DCACHEBSIZE and AT_HWCAP2 support for POWER PC
Valgrind currently does not support the following AUX vector entries:
AT_DCACHEBSIZE, and AT_HWCAP2. By default these entries are suppressed by
Valgrind. The attached patch adds the needed support so the user level programs
can correctly determine that hardware level they are running on. Specifically
that the ISA 2.07 for Power 8 is supported.
Bugzilla 345695
This fix adds the needed support. It makes a minor change to allow the
VEX settings of the host platform to be passed down so they can be checked
against the HWCAP values.
The files touched are:
coregrind/m_initimg/initimg-linux.c
coregrind/pub_core_initimg.h
coregrind/m_main.c
committed by Carl Love ce...@us...
Modified:
trunk/coregrind/m_initimg/initimg-linux.c
trunk/coregrind/m_main.c
trunk/coregrind/pub_core_initimg.h
Modified: trunk/coregrind/m_initimg/initimg-linux.c
==============================================================================
--- trunk/coregrind/m_initimg/initimg-linux.c (original)
+++ trunk/coregrind/m_initimg/initimg-linux.c Thu Apr 9 17:23:20 2015
@@ -246,6 +246,10 @@
/*=== Setting up the client's stack ===*/
/*====================================================================*/
+#ifndef AT_DCACHEBSIZE
+#define AT_DCACHEBSIZE 19
+#endif /* AT_DCACHEBSIZE */
+
#ifndef AT_ICACHEBSIZE
#define AT_ICACHEBSIZE 20
#endif /* AT_ICACHEBSIZE */
@@ -262,6 +266,10 @@
#define AT_RANDOM 25
#endif /* AT_RANDOM */
+#ifndef AT_HWCAP2
+#define AT_HWCAP2 26
+#endif /* AT_HWCAP2 */
+
#ifndef AT_EXECFN
#define AT_EXECFN 31
#endif /* AT_EXECFN */
@@ -377,8 +385,14 @@
const ExeInfo* info,
UInt** client_auxv,
Addr clstack_end,
- SizeT clstack_max_size )
+ SizeT clstack_max_size,
+ const VexArchInfo* vex_archinfo )
{
+ /* The HW configuration setting (hwcaps) of the target can be
+ * checked against the Vex settings of the host platform as given
+ * by the values in vex_archinfo.
+ */
+
SysRes res;
HChar **cpp;
HChar *strtab; /* string table */
@@ -690,8 +704,44 @@
}
# endif
break;
+# if defined(VGP_ppc64be_linux) || defined(VGP_ppc64le_linux)
+ case AT_HWCAP2:
+ /* The HWCAP2 value has the entry arch_2_07 which indicates the
+ * processor is a Power 8 or beyond. The Valgrind vai.hwcaps
+ * value (coregrind/m_machine.c) has the VEX_HWCAPS_PPC64_ISA2_07
+ * flag set so Valgrind knows about Power8. Need to pass the
+ * HWCAP2 value along so the user level programs can detect that
+ * the processor supports ISA 2.07 and beyond.
+ */
+ /* Power Architecture 64-Bit ELF V2 ABI Specification
+ July 21, 2014, version 1.0, Page 124
+ www-03.ibm.com/technologyconnect/tgcm/TGCMServlet.wss?alias=OpenPOWER&linkid=1n0000
+
+ AT_HWCAP2
+ The a_val member of this entry is a bit map of hardware
+ capabilities. Some bit mask values include:
+
+ PPC_FEATURE2_ARCH_2_07 0x80000000
+ PPC_FEATURE2_HAS_HTM 0x40000000
+ PPC_FEATURE2_HAS_DSCR 0x20000000
+ PPC_FEATURE2_HAS_EBB 0x10000000
+ PPC_FEATURE2_HAS_ISEL 0x08000000
+ PPC_FEATURE2_HAS_TAR 0x04000000
+ PPC_FEATURE2_HAS_VCRYPTO 0x02000000
+ */
+
+ if ((auxv->u.a_val & ~(0x80000000ULL)) != 0) {
+ /* Verify if PPC_FEATURE2_ARCH_2_07 is set in HWCAP2
+ * that arch_2_07 is also set in VEX HWCAPS
+ */
+ vg_assert((vex_archinfo->hwcaps & VEX_HWCAPS_PPC64_ISA2_07) == VEX_HWCAPS_PPC64_ISA2_07);
+ }
+
+ break;
+# endif
case AT_ICACHEBSIZE:
+ case AT_DCACHEBSIZE:
case AT_UCACHEBSIZE:
# if defined(VGP_ppc32_linux)
/* acquire cache info */
@@ -852,7 +902,8 @@
/*====================================================================*/
/* Create the client's initial memory image. */
-IIFinaliseImageInfo VG_(ii_create_image)( IICreateImageInfo iicii )
+IIFinaliseImageInfo VG_(ii_create_image)( IICreateImageInfo iicii,
+ const VexArchInfo* vex_archinfo )
{
ExeInfo info;
HChar** env = NULL;
@@ -913,7 +964,8 @@
iifii.initial_client_SP
= setup_client_stack( init_sp, env,
&info, &iifii.client_auxv,
- iicii.clstack_end, iifii.clstack_max_size );
+ iicii.clstack_end, iifii.clstack_max_size,
+ vex_archinfo );
VG_(free)(env);
Modified: trunk/coregrind/m_main.c
==============================================================================
--- trunk/coregrind/m_main.c (original)
+++ trunk/coregrind/m_main.c Thu Apr 9 17:23:20 2015
@@ -1822,9 +1822,12 @@
//--------------------------------------------------------------
// Figure out what sort of CPU we're on, and whether it is
// able to run V.
+ /* The vex_archinfo structure is passed down later to the client
+ * to verify the HW info settings are consistent.
+ */
+ VexArchInfo vex_archinfo;
VG_(debugLog)(1, "main", "Get hardware capabilities ...\n");
{ VexArch vex_arch;
- VexArchInfo vex_archinfo;
Bool ok = VG_(machine_get_hwcaps)();
if (!ok) {
VG_(printf)("\n");
@@ -1952,7 +1955,7 @@
# endif
/* NOTE: this call reads VG_(clo_main_stacksize). */
- the_iifii = VG_(ii_create_image)( the_iicii );
+ the_iifii = VG_(ii_create_image)( the_iicii, &vex_archinfo );
}
//==============================================================
Modified: trunk/coregrind/pub_core_initimg.h
==============================================================================
--- trunk/coregrind/pub_core_initimg.h (original)
+++ trunk/coregrind/pub_core_initimg.h Thu Apr 9 17:23:20 2015
@@ -33,6 +33,7 @@
#define __PUB_CORE_INITIMG_H
#include "pub_core_basics.h" // Addr
+#include "libvex.h"
//--------------------------------------------------------------------
// PURPOSE: Map the client executable into memory, then set up its
@@ -50,7 +51,8 @@
structure, which is gathered in an OS-specific way at startup.
This returns an IIFinaliseImageInfo structure: */
extern
-IIFinaliseImageInfo VG_(ii_create_image)( IICreateImageInfo );
+IIFinaliseImageInfo VG_(ii_create_image)( IICreateImageInfo,
+ const VexArchInfo* vex_archinfo );
/* Just before starting the client, we may need to make final
adjustments to its initial image. Also we need to set up the VEX
|
|
From: Julian S. <js...@ac...> - 2015-04-09 13:49:11
|
Bug 339778 (https://bugs.kde.org/show_bug.cgi?id=339778) contains patches for a port to TileGx, a 64 bit CPU. There has been quite some reviewing and re-working of the patches. From my point of view they are now ready to land. Are there any more comments or concerns regarding this bug? If so please say so now. If not I propose to land it in the next day or so. J |
|
From: Julian S. <js...@ac...> - 2015-04-09 11:57:42
|
On 05/04/15 12:25, Ivo Raisr wrote: >> I think r15034 (changes adding VG_(am_is_bogus_client_stack_pointer)()) >> causes some form of regression in stack extending. >> ... >> > Bug report: > https://bugs.kde.org/show_bug.cgi?id=345887 Austin English (cc'd) was reporting recently, some strange segfault loop phenomenon which might possibly be related. Unfortunately not easily reproducible. 345887 should be pretty simple to track down, though. J |
|
From: Julian S. <js...@ac...> - 2015-04-09 11:09:09
|
On 08/04/15 12:23, santosh wrote: >>> I still get the error: disInstr(ppc): unhandled instruction: 0x10E40301 >>> I thought Valgrind 3.10.1 has support for CPU: e500v2? NO? A general comment about e500 support. We've had people asking about this for several years now, and I think there are even some patches drifting around. From my point of view, the reason these haven't been committed is that they require proper integration with the existing POWER/PowerPC front end (guest_ppc_toIR.c). In particular, e500 has some instruction encodings which are interpreted as Altivec instructions in the "standard" POWER/PowerPC world. That means we can't simply commit e500 support as-is because it will completely break the existing POWER/PowerPC targets. Instead, the front end needs to know whether it is decoding for e500 or not. If someone could create a patch which has proper e500 hwcaps detection and uses that detection in the front end, and can verify that the patch really doesn't break existing POWER/PowerPC targets, then I'd be much more inclined to take it. That, as far as I am concerned, is really the limiting factor. J |
|
From: Pracheth J <pra...@ya...> - 2015-04-09 07:34:42
|
Hey,
The website says valgrind is supported for mips64/Linux platform. We want to know if it can be run on mips64/FreeBSD. Will the changes be huge?
The thing is ours is a legacy OS and any version after valgrind 3.4.1 will not work on this.
Regards,Pracheth
|
|
From: Rich C. <rc...@wi...> - 2015-04-09 04:10:07
|
I found one step missing. After creating the rootfs, you need to copy /usr/bin/qemu-arm-binfmt to rootfs/usr/bin, so that the binary can be found by the kernel once inside the chroot. Rich On Wed, 8 Apr 2015 08:35:09 -0500 Rich Coe <rc...@wi...> wrote: > 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... > > ------------------------------------------------------------------------------ > 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... |