|
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...
|