|
From: Julian S. <js...@ac...> - 2015-04-07 14:44:35
|
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 |
|
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: 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: 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: 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... |
|
From: Rich C. <rc...@wi...> - 2015-04-10 15:41:23
|
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 ppc from
openSUSE-13.2-DVD-ppc64-Build0023-Media.iso.
I removed all the xorg etc. packages and made a rootfs directory from the
files in created qemu partition. I copied /usr/bin/qemu-ppc64 and
/usr/bin/qemu-ppc64-binfmt to rootfs/usr/bin.
I installed: gcc gcc-c++ make SDL-devel automake autoconf subversion
I built valgrind with the following config parameters:
Maximum build arch: ppc64be
Primary build arch: ppc64be
Secondary build arch:
Build OS: linux
Primary build target: PPC64BE_LINUX
Secondary build target:
Platform variant: vanilla
Primary -DVGPV string: -DVGPV_ppc64be_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 try to run the tests, I get an invalid data memory access as shown below
and always from IP 0000000803762300.
Since it always happens, I suspect that something in the V framework is
consistently failing in the same place. I'll have to get into the V internals
more to understand where it's failing.
Here's the traceback from one of the core files:
#0 0x0000000803762780 in ?? ()
#1 0x63de619403724c50 in ?? ()
#2 0x00000000380d5054 in run_thread_for_a_while (two_words=two_words@entry=0x803724e00,
dispatchCtrP=dispatchCtrP@entry=0x803724e14, tid=tid@entry=1, alt_host_addr=98818,
alt_host_addr@entry=18446744073709551615, use_alt_host_addr=use_alt_host_addr@entry=255 '\377')
at m_scheduler/scheduler.c:929
#3 0x00000000380d75a4 in vgPlain_scheduler (tid=<optimized out>) at m_scheduler/scheduler.c:1318
#4 0x00000000380f0e30 in thread_wrapper (tidW=1) at m_syswrap/syswrap-linux.c:103
#5 run_a_thread_NORETURN (tidW=1) at m_syswrap/syswrap-linux.c:156
#6 0x0000000000000000 in ?? ()
(gdb) x/i $pc-4
0x380d5050 <run_thread_for_a_while+560>: bl 0x380c5ea8 <.vgPlain_disp_run_translations>
Here's the output from running the tool:
/usr/local/src/vg/.in_place/memcheck-ppc64be-linux --command-line-only=yes --memcheck:leak-check=no --tool=memcheck ./fwrite
Invalid instruction
NIP 00000000380766c0 LR 00000000380766b0 CTR 0000000000000000 XER 0000000000000000
MSR 8000000002806000 HID0 0000000000000000 HF 0000000002806000 idx 0
TB 00000000 00000000
GPR00 0000000038076330 000000003939bae0 0000000038262010 0000000000000000
GPR04 0000000028000022 000000003939b9f0 0000000000000008 0000000000000000
GPR08 0000000000000000 0000000000000001 0000000000000000 0000000000000000
GPR12 0000000000000008 0000000000000000 0000000000000003 00000040008000e8
GPR16 0000004000800512 000000003939bc90 00000000381e41d0 00000000381e7788
GPR20 00000000381e7748 00000000381e7760 0000000038225b90 0000000000000000
GPR24 00000000381e77c0 00000000381e77a0 00000000381e7770 00000000381e7750
GPR28 000000003824baa8 0000000000000001 0000000038a6a900 000000007ffffffb
CR 28000022 [ E L - - - - E E ] RES ffffffffffffffff
FPR00 7ff0000000000000 0000000000000000 0000000000000000 0000000000000000
FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPSCR ffffffff84002000
setup_frame: not implemented
==8095== Memcheck, a memory error detector
==8095== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==8095== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info
==8095== Command: ./fwrite
==8095==
==8095== Use of uninitialised value of size 8
==8095== at 0x401D620: _dl_sysdep_start (in /lib64/ld-2.19.so)
==8095== by 0x4004047: _dl_start_final (in /lib64/ld-2.19.so)
==8095== by 0x4007FEF: _dl_start (in /lib64/ld-2.19.so)
==8095== by 0x4003CCF: _start (in /lib64/ld-2.19.so)
==8095==
==8095== Use of uninitialised value of size 8
==8095== at 0x401D630: _dl_sysdep_start (in /lib64/ld-2.19.so)
==8095== by 0x4004047: _dl_start_final (in /lib64/ld-2.19.so)
==8095== by 0x4007FEF: _dl_start (in /lib64/ld-2.19.so)
==8095== by 0x4003CCF: _start (in /lib64/ld-2.19.so)
==8095==
==8095== Use of uninitialised value of size 8
==8095== at 0x401D6F4: _dl_sysdep_start (in /lib64/ld-2.19.so)
==8095== by 0x4004047: _dl_start_final (in /lib64/ld-2.19.so)
==8095== by 0x4007FEF: _dl_start (in /lib64/ld-2.19.so)
==8095== by 0x4003CCF: _start (in /lib64/ld-2.19.so)
==8095==
==8095== Use of uninitialised value of size 8
==8095== at 0x401E024: _dl_next_ld_env_entry (in /lib64/ld-2.19.so)
==8095== by 0x40048B3: dl_main (in /lib64/ld-2.19.so)
==8095== by 0x4004047: _dl_start_final (in /lib64/ld-2.19.so)
==8095== by 0x4007FEF: _dl_start (in /lib64/ld-2.19.so)
==8095== by 0x4003CCF: _start (in /lib64/ld-2.19.so)
==8095==
==8095== Use of uninitialised value of size 8
==8095== at 0x401E03C: _dl_next_ld_env_entry (in /lib64/ld-2.19.so)
==8095== by 0x40048B3: dl_main (in /lib64/ld-2.19.so)
==8095== by 0x4004047: _dl_start_final (in /lib64/ld-2.19.so)
==8095== by 0x4007FEF: _dl_start (in /lib64/ld-2.19.so)
==8095== by 0x4003CCF: _start (in /lib64/ld-2.19.so)
==8095==
==8095== Use of uninitialised value of size 8
==8095== at 0x400491C: dl_main (in /lib64/ld-2.19.so)
==8095== by 0x401D873: _dl_sysdep_start (in /lib64/ld-2.19.so)
==8095== by 0x4004047: _dl_start_final (in /lib64/ld-2.19.so)
==8095== by 0x4007FEF: _dl_start (in /lib64/ld-2.19.so)
==8095== by 0x4003CCF: _start (in /lib64/ld-2.19.so)
==8095==
Invalid data memory access: 0x0000000ffeffee80
NIP 0000000803762300 LR 0000000803762300 CTR 0000000038036c40 XER 0000000000000000
MSR 8000000002806000 HID0 0000000000000000 HF 0000000002806000 idx 0
TB 00000000 00000000
GPR00 00000008037622cc 0000000803724a10 0000000038262010 0000000ffeffee80
GPR04 000000003825a2c8 0000000000000000 00000000382622c8 0000000000003ba0
GPR08 0000000000005555 ffffffffffffaaaa 0000000802ba0000 0000000000000000
GPR12 0000000024000048 0000000000000000 0000000000000000 0000000ffeffee80
GPR16 0000000ffefff300 0000000000000000 0000000000000000 0000000ffefff300
GPR20 0000000000000002 0000000ffefff310 0000000000000000 0000000000000000
GPR24 ffffffffffffffbf ffffffffffffffff fffffffffffffffd 0000000038dc4158
GPR28 0000000038a72945 0000000038dc4158 000000000001820c 00000008031835c0
CR 24000082 [ E G - - - - L E ] RES ffffffffffffffff
FPR00 7ff0000000000000 0000000000000000 0000000000000000 0000000000000000
FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPSCR ffffffff00000000
Invalid segfault errno (42000000)
NIP 0000000803762300 LR 0000000803762300 CTR 0000000038036c40 XER 0000000000000000
MSR 8000000002806000 HID0 0000000000000000 HF 0000000002806000 idx 0
TB 00000000 00000000
GPR00 00000008037622cc 0000000803724a10 0000000038262010 0000000ffeffee80
GPR04 000000003825a2c8 0000000000000000 00000000382622c8 0000000000003ba0
GPR08 0000000000005555 ffffffffffffaaaa 0000000802ba0000 0000000000000000
GPR12 0000000024000048 0000000000000000 0000000000000000 0000000ffeffee80
GPR16 0000000ffefff300 0000000000000000 0000000000000000 0000000ffefff300
GPR20 0000000000000002 0000000ffefff310 0000000000000000 0000000000000000
GPR24 ffffffffffffffbf ffffffffffffffff fffffffffffffffd 0000000038dc4158
GPR28 0000000038a72945 0000000038dc4158 000000000001820c 00000008031835c0
CR 24000082 [ E G - - - - L E ] RES ffffffffffffffff
FPR00 7ff0000000000000 0000000000000000 0000000000000000 0000000000000000
FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPSCR ffffffff00000000
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
|
|
From: Rich C. <rc...@wi...> - 2015-04-10 23:16:19
|
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 |
|
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 > |