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
(23) |
2
(40) |
3
(17) |
4
(10) |
|
5
(14) |
6
(41) |
7
(26) |
8
(23) |
9
(15) |
10
(25) |
11
(14) |
|
12
(23) |
13
(11) |
14
(18) |
15
(21) |
16
(18) |
17
(8) |
18
(14) |
|
19
(16) |
20
(15) |
21
(12) |
22
(11) |
23
(8) |
24
(11) |
25
(12) |
|
26
(9) |
27
(17) |
28
(31) |
29
(16) |
30
(10) |
31
(17) |
|
|
From: Paul M. <pa...@sa...> - 2006-03-02 22:54:52
|
Julian Seward writes: > Ah. (Urk!) Thanks for the clarification. So the obvious question > is, do this ever really happen in Linux-land? By now the ppc32 > front end must have chewed through hundreds of megabytes of object > code without ever encountering any 64-bit insns. Sure. At present it would only happen if someone deliberately wrote assembler code to do it. Gcc compiling for a ppc32 target will never generate 64-bit instructions AFAIK. So no, it doesn't ever actually happen that I know of. (Of course, Murphy's law dictates that someone will pop up now and say "yes I do that in my HPC app and I really need to be able to Valgrind it". :) Paul. |
|
From: Julian S. <js...@ac...> - 2006-03-02 22:48:25
|
> There's a wrinkle here. [..] Ah. (Urk!) Thanks for the clarification. So the obvious question is, do this ever really happen in Linux-land? By now the ppc32 front end must have chewed through hundreds of megabytes of object code without ever encountering any 64-bit insns. J |
|
From: Paul M. <pa...@sa...> - 2006-03-02 22:39:23
|
Julian Seward writes: > Surely these are all 64-bit insns, so I'm not sure it's legit to run > them in 32-bit mode? If these *really* didn't work we wouldn't have a > working 64-bit port, since you can't get far in ppc64 land without > encountering rld* of some form. There's a wrinkle here. You are correct that they are 64-bit instructions, but 64-bit PPC processors allow you to execute 64-bit instructions in 32-bit mode. The 32-bit mode bit has only two effects: addresses are truncated to 32 bits, and the setting of CR0 by the record form of various instructions (i.e. the form with a "." on the end) is done based on the 32-bit result rather than the 64-bit result. A further wrinkle is that when a signal handler is invoked in a 32-bit process, only the bottom 32 bits of each register are saved in the stack frame by the Linux kernel and restored when the signal handler returns. Thus it *is* possible to use 64-bit instructions in a 32-bit program if you really know what you're doing - if you know that the program will only be run on a 64-bit processor and you have masked all signals that have handlers. (I have considered making the stack frame a bit bigger and saving the top 32 bits of each register in the extra space, but I haven't implemented that yet.) Whether it's worth adding the ability for Valgrind to handle 64-bit instructions in a ppc32 program is another question, of course. I think it would be perfectly reasonable and consistent for Valgrind to take the position that in 32-bit mode it is emulating a 32-bit processor, and 64-bit instructions are illegal. Regards, Paul. |
|
From: Paul M. <pa...@sa...> - 2006-03-02 20:49:47
|
Julian Seward writes: > We have the same problem on a 970 running YDL4. The fact that the > assembler barfs just means the assembler is old. It does not > necessarily mean the machine can't handle them. That's right. The POWER5 hardware certainly knows about mt/focrf. Paul. |
|
From: Julian S. <js...@ac...> - 2006-03-02 20:03:15
|
Hi .. as a side note, please mail questions like this to the dev list,
so that more people get to look at them - not just me.
We have the same problem on a 970 running YDL4. The fact that the
assembler barfs just means the assembler is old. It does not
necessarily mean the machine can't handle them. It may be that
Cerion was going to make a configure test which stops the test from
being done if the assembler can't handle the insn. I don't know
what the state of that is.
J
On Thursday 02 March 2006 19:45, Dave Nomura wrote:
> My nightly build on a Power5 machine is failing because apparently the
> optional instructions: mtocrf/mfocrf are not recognized by the
> assembler. the ppc970 machine's assembler does recognize them. I was
> wondering if the CPU revision number in /proc/cpuinfo possibly could be
> used to determine whether or not these instrs are going to be available.
> On the Power5, /proc/cpuinfo says:
> processor : 0
> cpu : POWER5 (gr)
> clock : 1504.352000MHz
> revision : 2.2
>
> -------- Original Message --------
> Subject: [Valgrind-developers] valgrind: r5705 - trunk/none/tests/ppc32
> Date: Wed, 1 Mar 2006 22:36:51 +0000 (GMT)
>
> Author: sewardj
> Date: 2006-03-01 22:36:49 +0000 (Wed, 01 Mar 2006)
> New Revision: 5705
>
> Log:
> A simple test of m{f,t}ocrf.
>
> Added:
> trunk/none/tests/ppc32/mftocrf.c
> trunk/none/tests/ppc32/mftocrf.stderr.exp
> trunk/none/tests/ppc32/mftocrf.stdout.exp
> trunk/none/tests/ppc32/mftocrf.vgtest
> Modified:
> trunk/none/tests/ppc32/Makefile.am
|
|
From: Julian S. <js...@ac...> - 2006-03-02 19:37:58
|
> 7fa87000-7fa9c000 rw-p 7fa87000 00:00 0 [stack] > ffffe000-fffff000 ---p 00000000 00:00 0 [vdso] That does indeed look like a 2+2 setup. As Tom says this is really quite unusual since it constrains the available address space for no obvious reason. Can you ask the Ubuntu kernel people why they are not using a traditional 3+1 rig? Your fix should work OK, I guess. It might be worth just sending the result of valgrind -d -d --tool=none date so we can check there's no bad interaction between V and anything else, like the stack. J |
|
From: Michael S. <ms...@xi...> - 2006-03-02 19:27:25
|
On 3/2/06, Julian Seward <js...@ac...> wrote: > > > I have a "fix" for my problem now. Why does this help? > > It changes where the tool asks to be loaded to be < 2G. Maybe you > have some strange address space layout (dictated by the kernel) > of 2G available and 2G for the kernel? What does 'cat /proc/self/maps' > (natively) show? > > J > It's a standard ubuntu dapper kernel (how 'standard' this actually is I don't know - but I haven't done anything funny with it) 08048000-0804c000 r-xp 00000000 08:02 4922006 /bin/cat 0804c000-0804d000 rw-p 00003000 08:02 4922006 /bin/cat 0804d000-0806e000 rw-p 0804d000 00:00 0 [heap] 77d33000-77d66000 r--p 00000000 08:02 5121458 =20 /usr/lib/locale/en_AU.utf8/LC_CTYPE 77d66000-77e3d000 r--p 00000000 08:02 5121461 =20 /usr/lib/locale/en_AU.utf8/LC_COLLATE 77e3d000-77e3e000 rw-p 77e3d000 00:00 0 77e3e000-77f67000 r-xp 00000000 08:02 346883 =20 /lib/tls/i686/cmov/libc-2.3.6.so 77f67000-77f6a000 rw-p 00129000 08:02 346883 =20 /lib/tls/i686/cmov/libc-2.3.6.so 77f6a000-77f6d000 rw-p 77f6a000 00:00 0 77f7a000-77f7b000 r--p 00000000 08:02 5121459 =20 /usr/lib/locale/en_AU.utf8/LC_NUMERIC 77f7b000-77f7c000 r--p 00000000 08:02 2012091 =20 /usr/lib/locale/en_AU.utf8/LC_TIME 77f7c000-77f7d000 r--p 00000000 08:02 2012253 =20 /usr/lib/locale/en_AU.utf8/LC_MONETARY 77f7d000-77f7e000 r--p 00000000 08:02 5121464 =20 /usr/lib/locale/en_AU.utf8/LC_MESSAGES/SYS_LC_MESSAGES 77f7e000-77f7f000 r--p 00000000 08:02 5121465 =20 /usr/lib/locale/en_AU.utf8/LC_PAPER 77f7f000-77f80000 r--p 00000000 08:02 5121466 =20 /usr/lib/locale/en_AU.utf8/LC_NAME 77f80000-77f81000 r--p 00000000 08:02 2012254 =20 /usr/lib/locale/en_AU.utf8/LC_ADDRESS 77f81000-77f82000 r--p 00000000 08:02 2012255 =20 /usr/lib/locale/en_AU.utf8/LC_TELEPHONE 77f82000-77f83000 r--p 00000000 08:02 5121469 =20 /usr/lib/locale/en_AU.utf8/LC_MEASUREMENT 77f83000-77f84000 r--p 00000000 08:02 2012256 =20 /usr/lib/locale/en_AU.utf8/LC_IDENTIFICATION 77f84000-77f87000 rw-p 77f84000 00:00 0 77f87000-77f9c000 r-xp 00000000 08:02 343871 /lib/ld-2.3.6.so 77f9c000-77f9d000 rw-p 00014000 08:02 343871 /lib/ld-2.3.6.so 7fa87000-7fa9c000 rw-p 7fa87000 00:00 0 [stack] ffffe000-fffff000 ---p 00000000 00:00 0 [vdso] Mike |
|
From: Tom H. <to...@co...> - 2006-03-02 19:26:13
|
In message <200...@fr...>
Duncan Sands <bal...@fr...> wrote:
> Also, there are more complicated cases. For example, consider "clone"
> (which is the syscall I'm really interested in). There are two system
> calls, a two argument one and a five argument one. The five argument one
> has a parameter child_tidptr which is only accessed if CLONE_CHILD_SETTID
> or CLONE_CHILD_CLEARTID is set in flags. If you do a normal clone library
> call without those bits set in flags (note: there is no child_tidptr
> argument in the library call), then the system library calls the five
> parameter syscall, using junk in child_tidptr, at least on my system. The
> author of the program has no control over that - the program is not wrong.
> The library is not really wrong either. But does this call for a
> suppression, or for extra logic in valgrind so that it only checks
> child_tidptr if an appropriate bit is set in flags?
There is only one clone system call actually - it has just been given
more parameters over time and flag bits are used to determine which of
those additional parameters are valid.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2006-03-02 19:25:15
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> > I have a "fix" for my problem now. Why does this help?
>
> It changes where the tool asks to be loaded to be < 2G. Maybe you
> have some strange address space layout (dictated by the kernel)
> of 2G available and 2G for the kernel? What does 'cat /proc/self/maps'
> (natively) show?
It does sound like he is using a 2+2 kernel yes, which is quite
unusual I think. A 3+1 split is traditional I think, and modern
systems often use a 4+0 split.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2006-03-02 19:22:50
|
In message <200...@fr...>
Duncan Sands <bal...@fr...> wrote:
> > Obviously it is a bit of a bug, but is not trivial to fix and
> > rarely causes a problem as people normal pass a constant -1 or
> > something when doing an anonymous map.
>
> I agree that it is not very important (and in fact I myself am
> not much interested in it - I'm interested in a more complicated
> case with sys_clone; mmap is a warmup). But why do you say it is
> not trivial to fix?
I was really just referring to the fact that checking the registers
is bound up in those macros that check everything at once, but it
looks like you have all that worked out.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2006-03-02 19:06:17
|
> I have a "fix" for my problem now. Why does this help? It changes where the tool asks to be loaded to be < 2G. Maybe you have some strange address space layout (dictated by the kernel) of 2G available and 2G for the kernel? What does 'cat /proc/self/maps' (natively) show? J |
|
From: Frederik D. <dew...@fr...> - 2006-03-02 19:05:41
|
Hi, I'd be interested in making Helgrind work again, and I've read the current code. I'd appreciate a few pointers: - Helgrind in Valgrind-2.2 took advantage of the LOCK operation to detect a bus_lock. From what I gathered in the guest_x86 code, there is no such equivalent in IR. Am I correct when I assume that Helgrind needs a kind of Ist_Lock instruction to work properly? - I think that the Eraser implementation code can work as-is. In fact most of the porting work would be in helgrind's hg_instrument function. Is that a correct assumption? - I didn't get the "we need to get thread operation tracking working again after the changes added in Valgrind 2.4.0" comment. What kind of information is needed that is not available in current Valgrind? Thank you for your time, Frederik |
|
From: Michael S. <ms...@xi...> - 2006-03-02 18:58:38
|
On 3/2/06, Julian Seward <js...@ac...> wrote:
>
> > On Thursday 02 March 2006 13:04, Michael Smith wrote:
> > I'm seeing a _very_ strange problem here trying to use valgrind-SVN.
>
> That's a bit strange. However, none of the 8 or so overnight
> builds reported any such problems last night or even in the last
> month or so.
I have a "fix" for my problem now. Why does this help? I have
absolutely no idea. I don't understand the startup stuff in valgrind
at all:
Index: configure.in
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- configure.in (revision 5707)
+++ configure.in (working copy)
@@ -123,7 +123,7 @@
i?86)
AC_MSG_RESULT([ok (${host_cpu})])
VG_ARCH=3D"x86"
- valt_load_address_normal=3D"0xb0000000"
+ valt_load_address_normal=3D"0x70000000"
valt_load_address_inner=3D"0xa0000000"
;;
I tried 0xa0000000, 0x90000000, and 0x80000000, which didn't work.
This value does.
Some kernel thing on this ubuntu kernel presumably doesn't like
loading the code that high, but as I said, I don't understand any of
this stuff properly.
Mike
|
|
From: <sv...@va...> - 2006-03-02 17:09:22
|
Author: sewardj
Date: 2006-03-02 17:09:16 +0000 (Thu, 02 Mar 2006)
New Revision: 5708
Log:
Detect/select 'mpicc' (from --with-mpicc=3D) and use that to build
libmpiwrap.so.
Modified:
trunk/auxprogs/Makefile.am
trunk/configure.in
Modified: trunk/auxprogs/Makefile.am
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/auxprogs/Makefile.am 2006-03-02 13:48:21 UTC (rev 5707)
+++ trunk/auxprogs/Makefile.am 2006-03-02 17:09:16 UTC (rev 5708)
@@ -25,17 +25,30 @@
=20
#------------------------- mpi wrappers -----------------------
# Build libmpiwrap.so for the primary target only.
+#
+# This is really horrible.
+#
# Don't let automake install this, since it puts it in the
# wrong place. Instead install it ourselves in the right
# place using the install-exec-local target below.
#
+# Also, automake isn't good at supporting non-$(CC) compilers.
+# But we need to use $(MPI_CC) here. Hence the nasty hack of
+# directly saying how to build libmpiwrap.so, instead of
+# using automake's standard gunk.
+#
if BUILD_MPIWRAP
noinst_PROGRAMS =3D libmpiwrap.so
-libmpiwrap_so_SOURCES =3D mpiwrap.c
-libmpiwrap_so_CFLAGS =3D $(AM_FLAG_M3264_PRI) \
- -g -O -fpic -fno-omit-frame-pointer \
- -I../include -I@MPI_PREFIX@/include
-libmpiwrap_so_LDFLAGS =3D $(AM_FLAG_M3264_PRI) -g -shared
+#libmpiwrap_so_SOURCES =3D mpiwrap.c
+#libmpiwrap_so_CFLAGS =3D $(AM_FLAG_M3264_PRI) \
+# -g -O -fpic -fno-omit-frame-pointer \
+# -I../include -I@MPI_PREFIX@/include
+#libmpiwrap_so_LDFLAGS =3D $(AM_FLAG_M3264_PRI) -g -shared
+libmpiwrap.so: mpiwrap.c
+ $(MPI_CC) -g -O -fno-omit-frame-pointer -fpic -shared \
+ -I../include -I@MPI_PREFIX@/include \
+ $(AM_FLAG_M3264_PRI) \
+ -o libmpiwrap.so mpiwrap.c
=20
install-exec-local:
# convert (eg) X86_LINUX to x86-linux
Modified: trunk/configure.in
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/configure.in 2006-03-02 13:48:21 UTC (rev 5707)
+++ trunk/configure.in 2006-03-02 17:09:16 UTC (rev 5708)
@@ -597,7 +597,31 @@
AC_CHECK_FUNCS([floor memchr memset mkdir strchr strdup strpbrk strrchr =
strstr semtimedop])
=20
=20
+# Do we have a useable mpicc (MPI-ised C compiler) ?
+MPI_CC=3D"mpicc"
+AC_ARG_WITH(mpicc,
+ [ --with-mpicc=3D Specify name of MPI-ised C compiler],
+ MPI_CC=3D$withval
+)
+AC_MSG_CHECKING([for usable mpicc])
+saved_CC=3D$CC
+CC=3D$MPI_CC
+AC_TRY_COMPILE(, [
+int main ( ) { return 0; }
+],
+[
+ac_have_mpicc=3Dyes
+AC_MSG_RESULT([$MPI_CC])
+], [
+ac_have_mpicc=3Dno
+AC_MSG_RESULT([no])
+])
+CC=3D$saved_CC
+
+
# First consider --with-mpi=3D..., then check for mpi.h
+saved_CC=3D$CC
+CC=3D$MPI_CC
MPI_PREFIX=3D"/usr"
AC_ARG_WITH(mpi,
[ --with-mpi=3D/path/to/mpi/install Specify location of MPI],
@@ -618,6 +642,7 @@
ac_have_mpi_h=3Dno
AC_MSG_RESULT([no])
])
+CC=3D$saved_CC
=20
#if test x$ac_have_mpi_h =3D xyes ; then
# AC_DEFINE(HAVE_MPI_H, 1, [Define to 1 if mpi.h is available.])
@@ -625,6 +650,7 @@
=20
AM_CONDITIONAL(BUILD_MPIWRAP, test x$ac_have_mpi_h =3D xyes)
AC_SUBST(MPI_PREFIX)
+AC_SUBST(MPI_CC)
=20
=20
# -------------------- ok. We're done. --------------------
|
|
From: Michael S. <ms...@xi...> - 2006-03-02 15:10:41
|
On 3/2/06, Julian Seward <js...@ac...> wrote: > > > On Thursday 02 March 2006 13:04, Michael Smith wrote: > > I'm seeing a _very_ strange problem here trying to use valgrind-SVN. > > That's a bit strange. However, none of the 8 or so overnight > builds reported any such problems last night or even in the last > month or so. Indeed, very strange! > > Are you sure you have a completely clean tree? The build system > isn't too hot at dependency tracking. What happens if you check out > a new tree and build that? I had actually done a 'make clean' before building it, knowing that sometimes problems like these are just due to dirty builds. However, I just tried checking out a fresh tree, rebuilding, and get precisely the same problem. Output shown below is from this fresh build. > > If that doesn't fix it, try running with -d -d, which shows lots of > startup detail. --trace-flags=3D10000000 is also worth adding. -d -d shows what I expected: things go fine until valgrind tries to launch the tool binary, then the tool is immediately killed. --trace-flags=3D10000000 produces no output at all (except the 'Killed' message that I get when running 'valgrind' with no arguments at all). With -d -d: msmith@freeze:~$ valgrind -d -d --28454:1:debuglog DebugLog system started by Stage 1, level 2 logging requested--28454:1:launcher no tool requested, defaulting to 'memcheck' --28454:1:launcher no client specified, defaulting platform to 'x86-linux' --28454:1:launcher launching /home/msmith/lib/valgrind/x86-linux/memcheck Killed msmith@freeze:~$ If I start with "valgrind --tool=3Dnone" the same happens (though obviously it says it's launching 'none' rather than memcheck. If I specify a non-existent tool I get the correct error about the tool not existing. So, the problem appears (to me) to be that the kernel doesn't like the tool binaries. This suggests that perhaps there's something wrong with how it's linked - but my linker knowledge is far too poor to know what to look at here. Happy to try any suggestions. Mike |
|
From: John R.
|
>>Yes it can. Many Linux x86 binary programs "just run" on *BSD x86 >>and on Sun Solaris x86. Both of these other systems require >>that the fd parameter to mmap be in range, or -1. > > > But do they enforce this requirement when running Linux binaries in > their emulation environment? Yes, they do. The emulatation environment is somewhat "thin"; a large portion is just table lookup to transliterate system call numbers, etc. It would be better if effort spent trying to squirm out of this situation were spent instead on avoiding it in the first place. The goal of using memcheck ought to be better software (more correct, more reliable, more robust in the face of environments that may have defects themselves), not "evading getting caught". -- |
|
From: <sv...@va...> - 2006-03-02 13:48:24
|
Author: sewardj
Date: 2006-03-02 13:48:21 +0000 (Thu, 02 Mar 2006)
New Revision: 5707
Log:
Build system hacks to build and install the MPI wrappers library when
a suitable mpi.h is found at configure time. This also adds the
configure flag --with-mpi=3D/path/to/mpi/install so that libmpiwrap.so
can be built against any given MPI installation.
libmpiwrap.so is built and installed for the primary target only. As
usual this all involves various unsavoury build-system hacks.
Fortunately they are all in auxprogs/Makefile.am and configure.in
don't interact with any of our existing build-system hacks :-)
Modified:
trunk/auxprogs/Makefile.am
trunk/auxprogs/mpiwrap.c
trunk/configure.in
Modified: trunk/auxprogs/Makefile.am
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/auxprogs/Makefile.am 2006-03-02 13:44:05 UTC (rev 5706)
+++ trunk/auxprogs/Makefile.am 2006-03-02 13:48:21 UTC (rev 5707)
@@ -23,3 +23,27 @@
#----------------------------------------------------------
=20
=20
+#------------------------- mpi wrappers -----------------------
+# Build libmpiwrap.so for the primary target only.
+# Don't let automake install this, since it puts it in the
+# wrong place. Instead install it ourselves in the right
+# place using the install-exec-local target below.
+#
+if BUILD_MPIWRAP
+noinst_PROGRAMS =3D libmpiwrap.so
+libmpiwrap_so_SOURCES =3D mpiwrap.c
+libmpiwrap_so_CFLAGS =3D $(AM_FLAG_M3264_PRI) \
+ -g -O -fpic -fno-omit-frame-pointer \
+ -I../include -I@MPI_PREFIX@/include
+libmpiwrap_so_LDFLAGS =3D $(AM_FLAG_M3264_PRI) -g -shared
+
+install-exec-local:
+# convert (eg) X86_LINUX to x86-linux
+# really should use sed here, rather than assume tr is available
+ pD=3D`echo @VG_PLATFORM_PRI@ | tr A-Z_ a-z-` ; \
+ $(mkinstalldirs) $(DESTDIR)$(valdir)/$$pD; \
+ $(INSTALL_PROGRAM) ./libmpiwrap.so $(DESTDIR)$(valdir)/$$pD
+endif
+#
+#----------------------------------------------------------
+
Modified: trunk/auxprogs/mpiwrap.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/auxprogs/mpiwrap.c 2006-03-02 13:44:05 UTC (rev 5706)
+++ trunk/auxprogs/mpiwrap.c 2006-03-02 13:48:21 UTC (rev 5707)
@@ -75,7 +75,6 @@
#include <pthread.h> /* pthread_mutex_{lock,unlock} */
=20
/* Include Valgrind magic macros for writing wrappers. */
-#include "../include/valgrind.h"
#include "../memcheck/memcheck.h"
=20
=20
@@ -84,7 +83,8 @@
/*------------------------------------------------------------*/
=20
/* Include headers for whatever MPI implementation the wrappers are to
- be used with. */
+ be used with. The configure system will tell us what the path to
+ the chosen MPI implementation is, via -I.. to the compiler. */
#include "mpi.h"
=20
/* Where are API symbols?
Modified: trunk/configure.in
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/configure.in 2006-03-02 13:44:05 UTC (rev 5706)
+++ trunk/configure.in 2006-03-02 13:48:21 UTC (rev 5707)
@@ -596,6 +596,39 @@
=20
AC_CHECK_FUNCS([floor memchr memset mkdir strchr strdup strpbrk strrchr =
strstr semtimedop])
=20
+
+# First consider --with-mpi=3D..., then check for mpi.h
+MPI_PREFIX=3D"/usr"
+AC_ARG_WITH(mpi,
+ [ --with-mpi=3D/path/to/mpi/install Specify location of MPI],
+ MPI_PREFIX=3D$withval
+)
+
+AC_MSG_CHECKING([for $MPI_PREFIX/include/mpi.h])
+
+AC_TRY_COMPILE(, [
+#include "$MPI_PREFIX/include/mpi.h"
+int main ( int argc, char** argv )=20
+ { int r =3D MPI_Init(&argc,&argv); return 0 ; }
+],
+[
+ac_have_mpi_h=3Dyes
+AC_MSG_RESULT([yes])
+], [
+ac_have_mpi_h=3Dno
+AC_MSG_RESULT([no])
+])
+
+#if test x$ac_have_mpi_h =3D xyes ; then
+# AC_DEFINE(HAVE_MPI_H, 1, [Define to 1 if mpi.h is available.])
+#fi
+
+AM_CONDITIONAL(BUILD_MPIWRAP, test x$ac_have_mpi_h =3D xyes)
+AC_SUBST(MPI_PREFIX)
+
+
+# -------------------- ok. We're done. --------------------
+
AC_OUTPUT(
Makefile=20
valgrind.spec
@@ -652,7 +685,7 @@
cat<<EOF
=20
Primary build target: ${VG_PLATFORM_PRI}
- Secondary target: ${VG_PLATFORM_SEC}
+ Secondary build target: ${VG_PLATFORM_SEC}
Default supp files: ${DEFAULT_SUPP}
=20
EOF
|
|
From: <sv...@va...> - 2006-03-02 13:44:13
|
Author: sewardj
Date: 2006-03-02 13:44:05 +0000 (Thu, 02 Mar 2006)
New Revision: 5706
Log:
Update
Modified:
trunk/docs/internals/3_1_BUGSTATUS.txt
Modified: trunk/docs/internals/3_1_BUGSTATUS.txt
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/docs/internals/3_1_BUGSTATUS.txt 2006-03-01 22:36:49 UTC (rev 5=
705)
+++ trunk/docs/internals/3_1_BUGSTATUS.txt 2006-03-02 13:44:05 UTC (rev 5=
706)
@@ -12,21 +12,21 @@
v5470 v5479 117332 missing line info with icc 8.1 (x86)
pending pending 117362 partially defined equality
pending pending 117366 amd64: 0xDD 0x7C fnstsw
+ =3D=3D 118274
pending pending 117367 amd64: 0xD9 0xF4 fxtract
v5256 v5260 117369 amd64: __NR_getpriority (140)
-vx1482 vx1514 117419 ppc32: lfsu f5, -4(r11) (TODO: VERIFY 31BRA=
NCH)
-vx1492 vx1515 117419 ppc32: fsqrt (TODO: VERIFY 31BRA=
NCH)
+vx1482 vx1514 117419 ppc32: lfsu f5, -4(r11)
+vx1492 vx1515 117419 ppc32: fsqrt
pending wontfix n-i-bz ppc32: jm-insns doesn't do FP tests
pending wontfix 117564 __NR_clone param test (w/ partial patch)
v5514 v5671 117936 more stabs problems
=3D=3D119914
=3D=3D120345
pending pending 118118 SIGBUS in disInstr_AMD64 after long run
-pending pending 118239 amd64: 0xF 0xAE 0x3F (clflush)
-pending pending 118274 amd64: 0xDD #7 (fnsave)
+vx1533 pending 118239 amd64: 0xF 0xAE 0x3F (clflush)
pending pending 118466 add %r,%r mishandled by memcheck
v5635 v5672 118939 vm86old system call
-pending pending n-i-bz VALGRIND_COUNT_LEAKS arg types (Olly Betts)
+many wontfix n-i-bz VALGRIND_COUNT_LEAKS arg types (Olly Betts)
v5429 v5450 n-i-bz memcheck/tests/mempool reads freed memory
v5366/67/70 v5480 n-i-bz AshleyP's custom-allocator assertion
vx1501 vx1516 n-i-bz Dirk strict-aliasing stuff
@@ -53,11 +53,14 @@
pending pending 121662 x86: lock xadd (0xF0 0xF 0xC0 0x2)
v5647 v5678 121893 calloc does not always zero memory
pending pending n-i-bz XML output truncated (users, Jan 26 09:08:3=
4 2006)
-pending pending 121896 Handling ESP modification in ucontext from =
signal handlers
+pending pending 121896 ESP modification in ucontext from signal ha=
ndlers
+ (closed INVALID)
v5651 v5679 121901 no support for syscall tkill
v5700 v5701 n-i-bz Suppression update for Debian unstable
+pending pending 122067 amd64: fcmovnu (0xDB 0xD9)
=20
-(next 3 are ppc32-specific FP problems)
+(next 4 are ppc32-specific FP problems)
+v5662 v5703 n-i-bz broken signal handling in ppc32/64 cpuid-in=
g
many v5694/5 n-i-bz ppc32 rounding mode problems
Is fixed properly in head
For 31BRANCH copy in r5591 kludge
@@ -77,6 +80,6 @@
119404 executing ssh from inside valgrind fails
=20
----
-last trawled 14 Feb 06:
- bug-mail: Looked at everything up to and including 12 Feb 06.
- v-userss: Looked at everything up to and including 14 Feb 06.
+last trawled 28 Feb 06:
+ bug-mail: Looked at everything up to and including 28 Feb 06.
+ v-users: Looked at everything up to and including 28 Feb 06.
|
|
From: Julian S. <js...@ac...> - 2006-03-02 13:13:42
|
> On Thursday 02 March 2006 13:04, Michael Smith wrote: > I'm seeing a _very_ strange problem here trying to use valgrind-SVN. That's a bit strange. However, none of the 8 or so overnight builds reported any such problems last night or even in the last month or so. Are you sure you have a completely clean tree? The build system isn't too hot at dependency tracking. What happens if you check out a new tree and build that? If that doesn't fix it, try running with -d -d, which shows lots of startup detail. --trace-flags=10000000 is also worth adding. J |
|
From: Michael S. <ms...@xi...> - 2006-03-02 13:04:53
|
Hi all,
I'm seeing a _very_ strange problem here trying to use valgrind-SVN.
I'm on an x86 system running ubuntu dapper - the system installed
valgrind ("valgrind-3.1.0-Debian") starts fine.
However, if I try to start my locally installed version (SVN from
around half an hour ago, built with "./autogen.sh=20
--prefix=3D/home/msmith && make && make install" - however, this was
also happening with an older build I had sitting around in my PATH
from - probably - a few weeks ago), I get this:
msmith@freeze:~$ valgrind
Killed
Further investigation with the help of strace shows that the valgrind
gets as far as starting the memcheck binary
/home/msmith/lib/valgrind/x86-linux/memcheck (if I use a different
tool, it starts a different binary, but the behaviour is identical),
then I get (at the end):
execve("/home/msmith/lib/valgrind/x86-linux/memcheck", ["valgrind"],
[/* 44 vars */]) =3D 0
+++ killed by SIGKILL +++
msmith@freeze:~$
If I try to directly run memcheck:
msmith@freeze:~$ strace /home/msmith/lib/valgrind/x86-linux/memcheck
execve("/home/msmith/lib/valgrind/x86-linux/memcheck",
["/home/msmith/lib/valgrind/x86-li"...], [/* 43 vars */]) =3D 0
+++ killed by SIGKILL +++
msmith@freeze:~$
If I start memcheck in gdb, set breakpoints on a few likely spots
(main, _start, _start_in_C), and run it, I never get to any of the
breakpoints, it looks like the SIGKILL arrives (from wherever - the
kernel?) before anything happens at all.
So, at this point I've exhausted my knowledge of how to debug this
sort of thing - I don't understand process startup in anywhere near
sufficient detail.
Has anyone else seen this? Any ideas at all about what is going on?
Oh, and finally, some versions of things that might be important:
gcc:
gcc (GCC) 4.0.3 20060212 (prerelease) (Ubuntu 4.0.2-9ubuntu1)
ld
GNU ld version 2.16.91 20060118 Debian GNU/Linux
kernel:
Linux version 2.6.15-16-386 (buildd@vernadsky) (gcc version 4.0.3
20060212 (prerelease) (Ubuntu 4.0.2-9ubuntu1)) #1 PREEMPT Mon Feb 20
16:38:26 UTC 2006
Thanks,
Mike
|
|
From: Julian S. <js...@ac...> - 2006-03-02 12:26:53
|
> rldcl > rldcr > rldic > rldicl > rldicr > rldimi > srdi > --9925-- Arch and hwcaps: PPC32, ppc32-int-flt-FX-GX Surely these are all 64-bit insns, so I'm not sure it's legit to run them in 32-bit mode? If these *really* didn't work we wouldn't have a working 64-bit port, since you can't get far in ppc64 land without encountering rld* of some form. J |
|
From: Julian S. <js...@ac...> - 2006-03-02 11:25:11
|
> On Thursday 02 March 2006 11:22, Tom Hughes wrote: > > We do have the technology now, and I did start work on fixing it, but > it is by no means complete. How far did you get? Do you have any patches lying around? J |
|
From: Tom H. <to...@co...> - 2006-03-02 11:22:52
|
In message <e2e...@ma...>
Bart Van Assche <bar...@gm...> wrote:
> Has anyone experience with tracking pthread-related events as
> emitted by the Valgrind core ? It looks like Valgrind 3.1.0's core
> only notifies my tool about thread_create() events, and no other
> events. I have verified with gdb that all of pthread_create(),
> pthread_join(), pthread_mutex_lock() and pthread_mutex_unlock() are
> called multiple times by the client application.
The thread tracking stuff is not really working at the moment - hence
the reason that helgrind is not working.
We do have the technology now, and I did start work on fixing it, but
it is by no means complete.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2006-03-02 11:22:11
|
You really need to be using the svn trunk for this, not 3.1.0. If you uncomment the #if 0'd stuff at the bottom of vg_preloaded.c then vg should at least intercept some of the pthread_* calls. However there is still a missing link, which is how to get from these wrappers (which run on the simulated cpu) to notifying your drd tool of thread events. What thread events do you need your tool to be notified of? J On Thursday 02 March 2006 10:55, Bart Van Assche wrote: > Hello, > > Has anyone experience with tracking pthread-related events as > emitted by the Valgrind core ? It looks like Valgrind 3.1.0's core > only notifies my tool about thread_create() events, and no other > events. I have verified with gdb that all of pthread_create(), > pthread_join(), pthread_mutex_lock() and pthread_mutex_unlock() are > called multiple times by the client application. > > The following code is present drd_pre_clo_init(): > > VG_(track_pre_mutex_lock) (drd_pre_mutex_lock); > VG_(track_post_mutex_lock) (drd_post_mutex_lock); > VG_(track_post_mutex_unlock) (drd_post_mutex_unlock); > VG_(track_post_thread_create)(drd_post_thread_create); > VG_(track_post_thread_join) (drd_post_thread_join); > > Shell output (the drd_... functions currently only print their name > and arguments, and the test program creates two threads): > $ inst/bin/valgrind --tool=drd ~/stc/build/posix/debug/stc-test 3 2>&1 > > | grep ^drd > > drd_post_thread_create tid = 0, child = 1 > drd_post_thread_create tid = 1, child = 2 > drd_post_thread_create tid = 1, child = 3 > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live > webcast and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Jean-Marc V.
|
Le jeudi 02 mars 2006 =E0 10:30 +0000, Julian Seward a =E9crit : > > DIV/IDIV > > First obvious case: if the denominator is undefined, then it can be > > zero, which would cause an exception. >=20 > I agree. Memcheck could do better here and it would be easy to do so. Good. > > A less obvious case is if the numerator is undefined and if (and only=20 > > if) the denominator is equal to -1. In this case, an exception could=20 > > also be generated if the undefined numerator end up being 0x80000000. >=20 > Could do, but is pretty obscure and would give some performance overhead. Would it? The check only needs to happen if the numerator is undefined in the first place. It's just that the error isn't reported if denominator!=3D0. > > FDIV > > Same as for DIV/IDIV, I think it should report an error if the > > demoninator is undefined. >=20 > With IEEE default exceptions set, which is the only FP exception > setting V supports, dividing by zero gives +Inf/-Inf, but no exception. The fact that the program really slows down on a float divide-by-zero, means that it's almost certainly a bug if that happens because of an undefined value. Could something like that be made an option? > > FIST/FISTP (Store Integer) > > Storing (converting) an uninitialized float value to int may cause an > > exception if the value is +-inf, NaN or too large for the int size. >=20 > My understanding on x86/amd64 is that the result is a value the docs call > 'integer indefinite', which is 0x8000...0000. And on ppc the same happen= s > except you get either 0x800... or 0x7FF.... Looked at the P4 docs and it says exception, although I guess it could be masked by default. This is probably the same issue as the float divide. > > I'm not sure about that one, but since any float operation > > (add,sub,mul,div,load,store,sqrt,...) can cause an exception if one of > > the operands is NaN, inf or denormalised, >=20 > Well, as per above, V only supports IEEE exceptions masked. Same as above I guess. > > SSE > > I don't think SSE arithmetic instructions can generate any exception, s= o > > it's probably safer not to report errors on SSE arithmetic operations. >=20 > I believe SSE FP arithmetic can generate exceptions. If it couldn't,=20 > SSE would be useless as a way of doing IEEE compliant FP arithmetic. SSE does support +-inf and NaN for results, but I was under the impression that it couldn't generate exceptions or slow down the CPU when inf/NaN gets generated. This is required for computing on a vector or 2-3 values without clearing the rest of the registers. Of course, I could be wrong, so please point me to the doc if this isn't right. > Yeh, I've heard of the P4 denormalised value performance disaster=20 > phenomenon before now. Detecting this would fall more into the area > of a profiling tool though. It wouldn't be hard to do. That would certainly be very useful for everyone doing either DSP or numerical simulations. Jean-Marc |