valgrind-users — General discussion list for Valgrind users

[Valgrind-users] question on valgrind's configure and build process

[janjust <tja...@un...>]

Hi,
 If certain instructions are not detected through configure process, does
that imply that a valgrind build will not be configured to handle these
instructions (i.e. fail at runtime)?

I have a system where my host nodes are somewhat different from my target
nodes (where the valgrind package will run) and I'm running into unhandled
instructions when running applications. I don't know if these instructions
are not supported because configure doesn't detect them during configure, or
if they truly are not - implemented?
Certain instructions that are not detected are AVX2 and BMI1/2, BUT, I'm not
sure if these are the culprits of unhandled instructions. I think I saw a
patch committed that handles these instructions.

checking if x86/amd64 assembler speaks AVX2... no
checking if x86/amd64 assembler speaks BMI1 and BMI2... no

I'm positive that my target node has them (AMD bulldozer/piledriver). But
again, if I try to compile the code snippets generated during ./configure
process it exits with the same error.

So this leaves me even more confused: is this a compiler/assembler issue (am
I missing a flag?), or an architecture issue.

Moreover, I don't really know which instructions are causing it to fail, how
do I check?
The line I get is:

21 vex amd64->IR: unhandled instruction bytes: 0xC4 0xE3 0xF1 0x6B 0x15 0x12
0x4 0x0
22 vex amd64->IR:   REX=0 REX.W=1 REX.R=0 REX.X=0 REX.B=0
23 vex amd64->IR:   VEX=1 VEX.L=0 VEX.nVVVV=0x1 ESC=0F3A
24 vex amd64->IR:   PFX.66=1 PFX.F2=0 PFX.F3=0
25 3=0

Can anyone clarify?

P.S.
  If you need more clarification regarding my system/compiler/os let me
know.
For what it's worth, it's a cray system composed of bulldozer/piledriver
CPUs, and the OS is cray CNL.




--
View this message in context: http://valgrind.10908.n7.nabble.com/question-on-valgrind-s-configure-and-build-process-tp46406.html
Sent from the Valgrind - Users mailing list archive at Nabble.com.

Re: [Valgrind-users] --trace-malloc=yes and backtrace

[Philippe W. <phi...@sk...>]

On Wed, 2013-08-21 at 11:12 +0400, Dmitry Antipov wrote: 
> I'm trying to use valgrind --tool=memcheck --trace-malloc=yes in attempt to
> find inefficient memory allocations and optimize them out. It would be nice
> to have an option to dump the backtrace for each malloc/realloc/free/etc.
> call as well. Is there such an option? If not, is it possible to implement
> something similar in the next version?

"inefficient memory allocation" : do you mean
   inefficient in cpu because a lot of malloc/free are done but
   memory usage is reasonable ?
or do you mean
   inefficient because it uses a lot of memory ?
      (in this case: is it a temporary peak memory usage ?
       or is memory usage just growing/big ?)

In both cases, you should be able to find the problem without
backtraces :

If the problem is cpu usage due to many malloc/free, callgrind
should be able to point at the culprit(s).
If the problem is peak memory usage, then massif should be able
to point at the culprit(s).
If the problem is just big/growing memory usage, then massif
and/or memcheck should be able to point at the culprit(s).

Philippe

[Valgrind-users] --trace-malloc=yes and backtrace

[Dmitry A. <dma...@ya...>]

I'm trying to use valgrind --tool=memcheck --trace-malloc=yes in attempt to
find inefficient memory allocations and optimize them out. It would be nice
to have an option to dump the backtrace for each malloc/realloc/free/etc.
call as well. Is there such an option? If not, is it possible to implement
something similar in the next version?

Thanks,
Dmitry

Re: [Valgrind-users] DESPERATE: Receiving confusing warnings during very short execution phase

[cleca <cle...@un...>]

On Fri, Aug 16, 2013 at 8:33 AM, cleca <clemens.cap@> wrote:

> == PASTE of parts of the complaints ==
>  Invalid read of size 8
> ==19525==    at 0x6E6E2CA: ??? (in
> /home/cap/workspace/kademlia2/libs/libc.so.6)

> You will get better backtraces if you install the "glibc-debuginfo"
> package. (Assuming you are using a Red Hat derivative.) Also, compile
> your application with "-g".

Actually I *did* compile with -g. But your remark had me check the line
above once more...which made me more suspicious and I replaced (my) version
of the libc by the system one (with which valgrind had been compiled).

And VOILA: Problem solved. All messages of valgrind make completely sense
now, whereas they looked absolutely chinese to be before. Probably the
mismatch of C-libraries threw valgrind under the bus. Interesting to see
that valgrind nevertheless was able to produce messages (which, however, did
not make sene to me). Would be nice if valgrind could detect/warn about
that.

THANK YOU very much for you help, it saved my day - I ws really a bit
desperate already.

> You can also try "gdb <my_program>" and then "x/10i 0x6E6E2CA" to see
> what the faulting instruction actually is. If you are lucky, it will
> be an SSE instruction and you can fix the warnings by using the latest
> Valgrind from Subversion and "--partial-loads-ok=yes".

Didn't know this trick and it probably will save my weekend - since I *am*
actually using some SSE-related code fragments which still are awaiting
valgrind-cleanup later today :-)

THANX.



--
View this message in context: http://valgrind.10908.n7.nabble.com/DESPERATE-Receiving-confusing-warnings-during-very-short-execution-phase-tp46345p46352.html
Sent from the Valgrind - Users mailing list archive at Nabble.com.

Re: [Valgrind-users] DESPERATE: Receiving confusing warnings during very short execution phase

[Patrick J. L. <lop...@gm...>]

On Fri, Aug 16, 2013 at 8:33 AM, cleca <cle...@un...> wrote:

> == PASTE of parts of the complaints ==
>  Invalid read of size 8
> ==19525==    at 0x6E6E2CA: ??? (in /home/cap/workspace/kademlia2/libs/libc.so.6)

You will get better backtraces if you install the "glibc-debuginfo"
package. (Assuming you are using a Red Hat derivative.) Also, compile
your application with "-g".

You can also try "gdb <my_program>" and then "x/10i 0x6E6E2CA" to see
what the faulting instruction actually is. If you are lucky, it will
be an SSE instruction and you can fix the warnings by using the latest
Valgrind from Subversion and "--partial-loads-ok=yes".

 - Pat

[Valgrind-users] DESPERATE: Receiving confusing warnings during very short execution phase

[cleca <cle...@un...>]

I am receiving numerous very confusing warnings by valgrind on a tiny initial
execution fragment of a large program.

The program fragment is as follows:

int main(int argc, const char* argv[]) {
  openlog  (NAME_OF_PROGRAM, LOG_NDELAY , LOG_USER);  
  syslog   (LOG_NOTICE, "Program is starting up at process id %d",
getpid());
  exit(1);
...
}

and valgrind presents many complaints (see below) for syslog. The main
function is part of a large c++ program, to which several libraries get
linked. On the other hand, if I run valgrind on a program consisting ONLY of
the above function, everything is fine.

I tried to pinpoint the responsible component, but since the code base is
rather large I am getting more and more desperate and see no strategy any
more for doing this...

== PASTE of parts of the complaints ==
 Invalid read of size 8
==19525==    at 0x6E6E2CA: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86416: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E88052: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86C87: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86DA8: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6EBFA8C: __vsyslog_chk (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6EC00BF: syslog (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x5EB1D2: main (kademlia.cpp:211)
==19525==  Address 0x757d650 is 16 bytes inside a block of size 20 alloc'd
==19525==    at 0x4C25D8C: malloc (vg_replace_malloc.c:270)
==19525==    by 0x6E86431: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E88052: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86C87: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86DA8: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6EBFA8C: __vsyslog_chk (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6EC00BF: syslog (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x5EB1D2: main (kademlia.cpp:211)
==19525== 
==19525== Invalid read of size 8
==19525==    at 0x6E6E2D3: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86416: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E88052: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86C87: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86DA8: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6EBFA8C: __vsyslog_chk (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6EC00BF: syslog (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x5EB1D2: main (kademlia.cpp:211)
==19525==  Address 0x757d658 is 4 bytes after a block of size 20 alloc'd
==19525==    at 0x4C25D8C: malloc (vg_replace_malloc.c:270)
==19525==    by 0x6E86431: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E88052: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86C87: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86DA8: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6EBFA8C: __vsyslog_chk (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6EC00BF: syslog (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x5EB1D2: main (kademlia.cpp:211)
==19525== 
==19525== Conditional jump or move depends on uninitialised value(s)
==19525==    at 0x6E6E2F2: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86416: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E88052: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86C87: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86DA8: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6EBFA8C: __vsyslog_chk (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6EC00BF: syslog (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x5EB1D2: main (kademlia.cpp:211)
==19525==  Uninitialised value was created by a heap allocation
==19525==    at 0x4C25D8C: malloc (vg_replace_malloc.c:270)
==19525==    by 0x6E87B86: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86C87: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86DA8: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6EBFA8C: __vsyslog_chk (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6EC00BF: syslog (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x5EB1D2: main (kademlia.cpp:211)
==19525== 
==19525== Use of uninitialised value of size 8
==19525==    at 0x6E6F6C4: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86416: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E88052: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86C87: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86DA8: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6EBFA8C: __vsyslog_chk (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6EC00BF: syslog (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x5EB1D2: main (kademlia.cpp:211)
==19525==  Uninitialised value was created by a heap allocation
==19525==    at 0x4C25D8C: malloc (vg_replace_malloc.c:270)
==19525==    by 0x6E87B86: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86C87: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86DA8: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6EBFA8C: __vsyslog_chk (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6EC00BF: syslog (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x5EB1D2: main (kademlia.cpp:211)
==19525== 
==19525== Use of uninitialised value of size 8
==19525==    at 0x6E6F6C8: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86416: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E88052: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86C87: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86DA8: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6EBFA8C: __vsyslog_chk (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6EC00BF: syslog (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x5EB1D2: main (kademlia.cpp:211)
==19525==  Uninitialised value was created by a heap allocation
==19525==    at 0x4C25D8C: malloc (vg_replace_malloc.c:270)
==19525==    by 0x6E87B86: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86C87: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86DA8: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6EBFA8C: __vsyslog_chk (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6EC00BF: syslog (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x5EB1D2: main (kademlia.cpp:211)
==19525== 
==19525== Invalid read of size 8
==19525==    at 0x6E6ECA4: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86416: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E88052: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86C87: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86DA8: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6EBFA8C: __vsyslog_chk (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6EC00BF: syslog (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x5EB1D2: main (kademlia.cpp:211)
==19525==  Address 0x757d6b0 is 16 bytes inside a block of size 21 alloc'd
==19525==    at 0x4C25D8C: malloc (vg_replace_malloc.c:270)
==19525==    by 0x6E86431: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E88052: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86C87: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86DA8: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6EBFA8C: __vsyslog_chk (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6EC00BF: syslog (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x5EB1D2: main (kademlia.cpp:211)
==19525== 
==19525== Conditional jump or move depends on uninitialised value(s)
==19525==    at 0x6E6FD19: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E863E2: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E88052: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86C87: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86DA8: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6EBFA8C: __vsyslog_chk (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6EC00BF: syslog (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x5EB1D2: main (kademlia.cpp:211)
==19525==  Uninitialised value was created by a heap allocation
==19525==    at 0x4C25D8C: malloc (vg_replace_malloc.c:270)
==19525==    by 0x6E87B86: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86C87: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86DA8: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6EBFA8C: __vsyslog_chk (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6EC00BF: syslog (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x5EB1D2: main (kademlia.cpp:211)
==19525== 
==19525== Conditional jump or move depends on uninitialised value(s)
==19525==    at 0x6E86402: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E88052: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86C87: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86DA8: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6EBFA8C: __vsyslog_chk (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6EC00BF: syslog (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x5EB1D2: main (kademlia.cpp:211)
==19525==  Uninitialised value was created by a heap allocation
==19525==    at 0x4C25D8C: malloc (vg_replace_malloc.c:270)
==19525==    by 0x6E87B86: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86C87: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6E86DA8: ??? (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6EBFA8C: __vsyslog_chk (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x6EC00BF: syslog (in
/home/cap/workspace/kademlia2/libs/libc.so.6)
==19525==    by 0x5EB1D2: main (kademlia.cpp:211)










--
View this message in context: http://valgrind.10908.n7.nabble.com/DESPERATE-Receiving-confusing-warnings-during-very-short-execution-phase-tp46345.html
Sent from the Valgrind - Users mailing list archive at Nabble.com.

Re: [Valgrind-users] Running Java 6 with -Xmx16G under Valgrind fails to instantiate heap

[Maynard J. <may...@us...>]

On 08/14/2013 03:43 AM, Julian Seward wrote:
> 
> For 3.8.1, I would expect that the biggest mmap you can do is limited to
> about 15G, so your -Xmx15G sounds about right. For trunk that got doubled,
> so I am also not surprised to hear you can manage -Xmx31G,
> 
> If you are prepared to do some minor fiddling with constants, I don't see
> why you can't do two more doubling steps so as to allow a 128G mmap:
Julian, thanks for the tips.  To get up to 127G, I did a "quadruple" step as described below.
> 
> To do a doubling step, do this:
> 
> 1.  in aspacemgr-linux.c, find this
>     #  if VG_WORDSIZE == 8
>          aspacem_maxAddr = (Addr)0x1000000000ULL - 1; // 64G
>     Change that to (Addr)0x200...
First, I just changed this to "(Addr)0x400..." and then ran my toy java app under valgrind memcheck.  Specifying '-Xmx' values up to 127G.  The higher I went, the slower memcheck appeared to run, varying from ~15% slowdown with -Xmx16G to ~20% slowdown with -Xmx127G.
> 
> 2.  in mc_main.c, find this
>     #  define N_PRIMARY_BITS  20
Then I changed this value to '22'.
> 
> 3.  in mc_main.c, find this
>     tl_assert(MASK(1) == 0xFFFFFFF000000000ULL);
>     Change 0xFFFFFFF000000000ULL to 0xFFFFFFE000000000ULL
and changed these assertions to check MASK(x) against 0xFFFFFFC00...

. . . and also had to change the MAX_PRIMARY_ADDRESS assertion to 0x3FFFFFFFFFULL.

>     ditto the other assertions
>     (the change moves the 1-0 boundary in the constant one bit upwards)
> 
> I suspect you may be able to get away with just (1) (worth a try), although
> you'll wind up with quite a large performance hit with Memcheck when
> accessing memory above the 64G boundary.  Adding in (2) and (3) should
> bring the performance level back to normal.
Once all these had been done, memcheck still ran slower (but not as much) -- between 8 and 12% slower, again, depending on the value of -Xmx.  Since the performance level didn't come back to "normal", maybe there's some other spot to change.

I presume there's a reason why these address ranges are set as they are.  Can you enlighten me?  Is there a possibility of making this configurable?

Thanks.
-Maynard
> 
> I'd be interested to hear if this actually works.
> 
> J
> 
> 
> On 08/13/2013 09:40 PM, Maynard Johnson wrote:
>> Hi,
>> A user reported a problem trying to run Java under Valgrind 3.8.1 when specifying a large value for the Java '-Xmx' option (128G).  The user was attempting to use Valgrind to do some analysis of "Watson" (of Jeopardy fame), running on a big IBM POWER7 system with tons of memory.  I reproduced the problem using a lower value for -Xmx on my IBM POWER7 development system, as well as on my laptop (an Intel Core 2 Duo).  On both systems, both the Valgrind and Java executables are 64-bit.  Below is the failing output from my laptop:
>>
>> [maynard@oc3431575272 myJavaStuff]$ valgrind --tool=none java -Xmx16G  ThreadLoop 1
>> ==13873== Nulgrind, the minimal Valgrind tool
>> ==13873== Copyright (C) 2002-2012, and GNU GPL'd, by Nicholas Nethercote.
>> ==13873== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
>> ==13873== Command: java -Xmx16G ThreadLoop 1
>> ==13873== 
>> JVMJ9VM015W Initialization error for library j9gc24(2): Failed to instantiate heap; 16G requested
>> Could not create the Java virtual machine.
>> ==13873== 
>>
>> --------------------------------------------
>>
>> On both systems, if I decreased the -Xmx value to 15G, the error did not occur.  Is this a known limitation?  Is there any way to work around this issue?
>>
>> I dumped the /proc/<pid>/maps file on my laptop for several runs, specifying different values for '-Xmx' (lower than 16G, of course). For each run, I saw a "[heap]" entry whose size matched whatever I specified for -Xmx. On the POWER7 system, the /proc/<pid>/maps file didn't have a '[heap]' entry.  I've attached maps files from the POWER7 and my laptop in case they may be of help.
>>
>> I also tried the same test with current upstream Valgrind.  On the POWER7 system, I did see a little improvement -- I was able to use -Xmx values up to 31G --but not enough improvement for the user doing the Watson analysis. I wasn't able to run the java test using upstream Valgrind on my laptop because Valgrind dies with a SIGSEGV (I'll report that problem in a separate posting).
>>
>> Thanks for any help anyone can offer.
>> -Maynard
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>> It's a free troubleshooting tool designed for production.
>> Get down to code-level detail for bottlenecks, with <2% overhead. 
>> Download for free and get started troubleshooting in minutes. 
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>>
>>
>>
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>>
> 

Re: [Valgrind-users] Running Java 6 with -Xmx16G under Valgrind fails to instantiate heap

[Julian S. <js...@ac...>]

For 3.8.1, I would expect that the biggest mmap you can do is limited to
about 15G, so your -Xmx15G sounds about right. For trunk that got doubled,
so I am also not surprised to hear you can manage -Xmx31G,

If you are prepared to do some minor fiddling with constants, I don't see
why you can't do two more doubling steps so as to allow a 128G mmap:

To do a doubling step, do this:

1.  in aspacemgr-linux.c, find this
    #  if VG_WORDSIZE == 8
         aspacem_maxAddr = (Addr)0x1000000000ULL - 1; // 64G
    Change that to (Addr)0x200...

2.  in mc_main.c, find this
    #  define N_PRIMARY_BITS  20

3.  in mc_main.c, find this
    tl_assert(MASK(1) == 0xFFFFFFF000000000ULL);
    Change 0xFFFFFFF000000000ULL to 0xFFFFFFE000000000ULL
    ditto the other assertions
    (the change moves the 1-0 boundary in the constant one bit upwards)

I suspect you may be able to get away with just (1) (worth a try), although
you'll wind up with quite a large performance hit with Memcheck when
accessing memory above the 64G boundary.  Adding in (2) and (3) should
bring the performance level back to normal.

I'd be interested to hear if this actually works.

J


On 08/13/2013 09:40 PM, Maynard Johnson wrote:
> Hi,
> A user reported a problem trying to run Java under Valgrind 3.8.1 when specifying a large value for the Java '-Xmx' option (128G).  The user was attempting to use Valgrind to do some analysis of "Watson" (of Jeopardy fame), running on a big IBM POWER7 system with tons of memory.  I reproduced the problem using a lower value for -Xmx on my IBM POWER7 development system, as well as on my laptop (an Intel Core 2 Duo).  On both systems, both the Valgrind and Java executables are 64-bit.  Below is the failing output from my laptop:
> 
> [maynard@oc3431575272 myJavaStuff]$ valgrind --tool=none java -Xmx16G  ThreadLoop 1
> ==13873== Nulgrind, the minimal Valgrind tool
> ==13873== Copyright (C) 2002-2012, and GNU GPL'd, by Nicholas Nethercote.
> ==13873== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
> ==13873== Command: java -Xmx16G ThreadLoop 1
> ==13873== 
> JVMJ9VM015W Initialization error for library j9gc24(2): Failed to instantiate heap; 16G requested
> Could not create the Java virtual machine.
> ==13873== 
> 
> --------------------------------------------
> 
> On both systems, if I decreased the -Xmx value to 15G, the error did not occur.  Is this a known limitation?  Is there any way to work around this issue?
> 
> I dumped the /proc/<pid>/maps file on my laptop for several runs, specifying different values for '-Xmx' (lower than 16G, of course). For each run, I saw a "[heap]" entry whose size matched whatever I specified for -Xmx. On the POWER7 system, the /proc/<pid>/maps file didn't have a '[heap]' entry.  I've attached maps files from the POWER7 and my laptop in case they may be of help.
> 
> I also tried the same test with current upstream Valgrind.  On the POWER7 system, I did see a little improvement -- I was able to use -Xmx values up to 31G --but not enough improvement for the user doing the Watson analysis. I wasn't able to run the java test using upstream Valgrind on my laptop because Valgrind dies with a SIGSEGV (I'll report that problem in a separate posting).
> 
> Thanks for any help anyone can offer.
> -Maynard
> 
> 
> 
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead. 
> Download for free and get started troubleshooting in minutes. 
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> 
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 

Re: [Valgrind-users] Running Java 5 under Valgrind results in Valgrind silently dying

[Julian S. <js...@ac...>]

On 08/13/2013 10:27 PM, Maynard Johnson wrote:

> When I try running Java 5 under current Valgrind (checkout from SVN today),
> it results in Valgrind silently dying.  The JVM continues to run, but only
> the java process shows up in 'top' output.  If I run Java 6 under
> Valgrind
> (i.e., 'valgrind --tool=memcheck /opt/ibm/java-ppc64-60/jre/bin/java test'),
> I see all of the typical kind of memcheck output, as well as the 'memcheck-ppc64-'
> command listed in top output.  I'm seeing this problem on IBM POWER7/RHEL 6.4,
> but I don't have a Java 5 available for my laptop to test it on Intel.
> Is this a ppc64-specific problem? Or an IBM Java-specific problem?
> Can anyone reproduce with Java 5 on an Intel system? Thanks.

I can't guess .. can you get more info about the failure?  Also, as per
other postings, you need --smc-check=all-non-file for Java anything on
x86.

J

[Valgrind-users] Running Java 5 under Valgrind results in Valgrind silently dying

[Maynard J. <may...@us...>]

Hi,
When I try running Java 5 under current Valgrind (checkout from SVN today), it results in Valgrind silently dying.  The JVM continues to run, but only the java process shows up in 'top' output.  If I run Java 6 under Valgrind (i.e., 'valgrind --tool=memcheck /opt/ibm/java-ppc64-60/jre/bin/java test'), I see all of the typical kind of memcheck output, as well as the 'memcheck-ppc64-' command listed in top output.  I'm seeing this problem on IBM POWER7/RHEL 6.4, but I don't have a Java 5 available for my laptop to test it on Intel.  Is this a ppc64-specific problem? Or an IBM Java-specific problem?  Can anyone reproduce with Java 5 on an Intel system? Thanks.

-Maynard

[Valgrind-users] Running Java 6 with -Xmx16G under Valgrind fails to instantiate heap

[Maynard J. <may...@us...>]

Hi,
A user reported a problem trying to run Java under Valgrind 3.8.1 when specifying a large value for the Java '-Xmx' option (128G).  The user was attempting to use Valgrind to do some analysis of "Watson" (of Jeopardy fame), running on a big IBM POWER7 system with tons of memory.  I reproduced the problem using a lower value for -Xmx on my IBM POWER7 development system, as well as on my laptop (an Intel Core 2 Duo).  On both systems, both the Valgrind and Java executables are 64-bit.  Below is the failing output from my laptop:

[maynard@oc3431575272 myJavaStuff]$ valgrind --tool=none java -Xmx16G  ThreadLoop 1
==13873== Nulgrind, the minimal Valgrind tool
==13873== Copyright (C) 2002-2012, and GNU GPL'd, by Nicholas Nethercote.
==13873== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==13873== Command: java -Xmx16G ThreadLoop 1
==13873== 
JVMJ9VM015W Initialization error for library j9gc24(2): Failed to instantiate heap; 16G requested
Could not create the Java virtual machine.
==13873== 

--------------------------------------------

On both systems, if I decreased the -Xmx value to 15G, the error did not occur.  Is this a known limitation?  Is there any way to work around this issue?

I dumped the /proc/<pid>/maps file on my laptop for several runs, specifying different values for '-Xmx' (lower than 16G, of course). For each run, I saw a "[heap]" entry whose size matched whatever I specified for -Xmx. On the POWER7 system, the /proc/<pid>/maps file didn't have a '[heap]' entry.  I've attached maps files from the POWER7 and my laptop in case they may be of help.

I also tried the same test with current upstream Valgrind.  On the POWER7 system, I did see a little improvement -- I was able to use -Xmx values up to 31G --but not enough improvement for the user doing the Watson analysis. I wasn't able to run the java test using upstream Valgrind on my laptop because Valgrind dies with a SIGSEGV (I'll report that problem in a separate posting).

Thanks for any help anyone can offer.
-Maynard

Re: [Valgrind-users] Using memcheck to treat memory as read-only

[Philippe W. <phi...@sk...>]

On Wed, 2013-08-07 at 08:13 -0700, John Reiser wrote:
> > Is there any support in memcheck for a client request to treat a block of memory as read-only?  I know memory can be defined as accessible/not accessible or defined/undefined, but I don’t see anything for “writable”.  It would be really nice to be able to add client requests so that after a block of
> > memory is initialized, to be able to tell memcheck that certain bytes should never be written again, because they have been initialized (e.g. pointer to another object).
> 
> No; "read only" is not one of the states in the current memory accounting info.
Effectively.
memcheck/mc_main.c gives some background info:
   Aside: the V+A bits are less precise than they could be -- we have no way
   of marking memory as read-only.  It would be great if we could add an
   extra state VA_BITSn_READONLY.  But then we'd have 5 different states,
   which requires 2.3 bits to hold, and there's no way to do that elegantly
   -- we'd have to double up to 4 bits of metadata per byte, which doesn't
   seem worth it.

Re: [Valgrind-users] Using memcheck to treat memory as read-only

[John R. <jr...@Bi...>]

> Is there any support in memcheck for a client request to treat a block of memory as read-only?  I know memory can be defined as accessible/not accessible or defined/undefined, but I don’t see anything for “writable”.  It would be really nice to be able to add client requests so that after a block of
> memory is initialized, to be able to tell memcheck that certain bytes should never be written again, because they have been initialized (e.g. pointer to another object).

No; "read only" is not one of the states in the current memory accounting info.

Re: [Valgrind-users] Request for ideas for Valgrind improvements (general or ARM)

[John R. <jr...@Bi...>]

> And a couple of words about cross-platform checking. If I did understand you correct you propose smth like running valgrind under quemu (1) or whole quemu under valgrind (2).

I was thinking of running memcheck(valgrind) compiled for x86_64,
running on x86_64 under Linux, but checking a target program that was
compiled for ARM and designed for Android.  If the SDK for Android
runs on x86_64 under Linux but emulates ARM for Android, then
the memcheck JIT engine can do the same thing but also perform
its checks of memory accesses, malloc+free, etc.

[Valgrind-users] Using memcheck to treat memory as read-only

[Phil L. <plo...@sa...>]

Is there any support in memcheck for a client request to treat a block of memory as read-only?  I know memory can be defined as accessible/not accessible or defined/undefined, but I don't see anything for "writable".  It would be really nice to be able to add client requests so that after a block of memory is initialized, to be able to tell memcheck that certain bytes should never be written again, because they have been initialized (e.g. pointer to another object).

Phil

Re: [Valgrind-users] Request for ideas for Valgrind improvements (general or ARM)

[Vasily G. <vas...@gm...>]

OK, thanks!

And a couple of words about cross-platform checking. If I did understand
you correct you propose smth like running valgrind under quemu (1) or whole
quemu under valgrind (2).

(2) - will be significantly slower because we need to instrument whole
system (not one binary\application)
(1) - as far as I know only code generation (from arm to x86 binary) made
by quemu-user decreases work of application x4. And we will need to use
system-wide quemu (not only user) that also decreases speed. So, now ARM
has more than 1GHz and we will not improve situation with 4Ghz host.

I think that we can use assessment of quemu even if we plan write our own
VM in Valgrind. Maybe I am wrong.


On Wed, Aug 7, 2013 at 4:54 PM, John Reiser <jr...@bi...> wrote:

> >     Can you specify some areas where 64 bit ARM is being used?
> >     I mean some links on real devices, systems, etc.?
> >     Does some company use it in mobile devices (phones, tablets)?
>
> So far, 64-bit ARM is for use in data centers which desire
> lower power consumption and lower cooling costs, but still
> must handle larger address spaces.  Battery-powered or
> portable devices prefer 32 bits because of monetary cost,
> physical size, and software issues.
>
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>



-- 
Best Regards,
Vasily

Re: [Valgrind-users] Request for ideas for Valgrind improvements (general or ARM)

[John R. <jr...@Bi...>]

>     Can you specify some areas where 64 bit ARM is being used?
>     I mean some links on real devices, systems, etc.?
>     Does some company use it in mobile devices (phones, tablets)?

So far, 64-bit ARM is for use in data centers which desire
lower power consumption and lower cooling costs, but still
must handle larger address spaces.  Battery-powered or
portable devices prefer 32 bits because of monetary cost,
physical size, and software issues.

Re: [Valgrind-users] Request for ideas for Valgrind improvements (general or ARM)

[Vasily G. <vas...@gm...>]

Sorry,
In fact, previous question was for Mr. Reiser according to his answer.



On Wed, Aug 7, 2013 at 10:53 AM, Vasily Golubev <vas...@gm...>wrote:

> Mr. Tokarev,
>
> Can you specify some areas where 64 bit ARM is being used?
> I mean some links on real devices, systems, etc.?
> Does some company use it in mobile devices (phones, tablets)?
>
>
> Thanks
>
>
> On Tue, Aug 6, 2013 at 2:18 PM, Konstantin Tokarev <an...@ya...>wrote:
>
>>
>>
>> 06.08.2013, 08:23, "John Reiser" <jr...@Bi...>:
>> > Only two areas really matter:
>> > 1. speed of memcheck
>> > 2. 64-bit ARM
>> >
>> > The most likely path to better speed is to make cross-platform checking
>> work.
>> > Check an ARM target program by running memcheck on a fast x86* CPU
>> (>=4GHz)
>> > with a large data cache (>=8MB) under a "compatible" operating system.
>> > Translating system calls might be tedious but should not be onerous.
>>
>> That would be quite useful not only for ARM, but for PPC and MIPS too.
>>
>> --
>> Regards,
>> Konstantin
>>
>>
>> ------------------------------------------------------------------------------
>> Get your SQL database under version control now!
>> Version control is standard for application code, but databases havent
>> caught up. So what steps can you take to put your SQL databases under
>> version control? Why should you start doing it? Read more to find out.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>>
>
>
>
> --
> Best Regards,
> Vasily
>



-- 
Best Regards,
Vasily

Re: [Valgrind-users] Request for ideas for Valgrind improvements (general or ARM)

[Vasily G. <vas...@gm...>]

Mr. Tokarev,

Can you specify some areas where 64 bit ARM is being used?
I mean some links on real devices, systems, etc.?
Does some company use it in mobile devices (phones, tablets)?


Thanks


On Tue, Aug 6, 2013 at 2:18 PM, Konstantin Tokarev <an...@ya...>wrote:

>
>
> 06.08.2013, 08:23, "John Reiser" <jr...@Bi...>:
> > Only two areas really matter:
> > 1. speed of memcheck
> > 2. 64-bit ARM
> >
> > The most likely path to better speed is to make cross-platform checking
> work.
> > Check an ARM target program by running memcheck on a fast x86* CPU
> (>=4GHz)
> > with a large data cache (>=8MB) under a "compatible" operating system.
> > Translating system calls might be tedious but should not be onerous.
>
> That would be quite useful not only for ARM, but for PPC and MIPS too.
>
> --
> Regards,
> Konstantin
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>



-- 
Best Regards,
Vasily

Re: [Valgrind-users] Unhandled instruction in libm

[Julian S. <js...@ac...>]

On 08/06/2013 10:07 PM, Florian Krohm wrote:
> No work-around really, other than recompiling libm with a suitable set
> of compiler flags (I would not know what those are).

I'm pretty sure this is caused by an AMD-specific insn set extension,
but I don't know which one.  If you constrain the compiler to avoid
AMD-specifics you might be better off.

Also, try using the valgrind svn trunk as the insn set support has
been updated since 3.8.1.  I'd say it's less likely to help, but is
worth a try.

svn co svn://svn.valgrind.org/valgrind/trunk
cd trunk
./autogen.sh
Then configure and build as with the tarball.

J

Re: [Valgrind-users] Unhandled instruction in libm

[Florian K. <br...@ac...>]

On 08/06/2013 08:02 PM, Kingsley, James Leonard wrote:
> Attempting to use valgrind on my system gives me an 'unrecognised instruction' error.  I am reasonably sure that it's a valgrind issue
> 

Yes, it is.

> vex amd64->IR: unhandled instruction bytes: 0xC4 0xE3 0xD9 0x6B 0x3D 0x4E 0x19 0x6
> vex amd64->IR:   REX=0 REX.W=1 REX.R=0 REX.X=0 REX.B=0
> vex amd64->IR:   VEX=1 VEX.L=0 VEX.nVVVV=0x4 ESC=0F3A
> vex amd64->IR:   PFX.66=1 PFX.F2=0 PFX.F3=0
> ==25013== valgrind: Unrecognised instruction at address 0x4c37a00.
> ==25013==    at 0x4C37A00: __ieee754_log_sse2 (in /lib64/libm-2.15.so)

This function has caused trouble before. See
https://bugs.kde.org/show_bug.cgi?id=320965

> 
> Any suggestions on fixing this?  

No work-around really, other than recompiling libm with a suitable set
of compiler flags (I would not know what those are).
If you're brave and have some time, you might be interested in adding
support for this instruction to valgrind. The code to look at would be
in <valgrind>/VEX/priv/guest_amd64_toIR.c, function disInstr_AMD64_WRK
and underneath.

   Florian

[Valgrind-users] Unhandled instruction in libm

[Kingsley, J. L. <jki...@WP...>]

Attempting to use valgrind on my system gives me an 'unrecognised instruction' error.  I am reasonably sure that it's a valgrind issue

Minimal working example:
----------------
#include <stdio.h>
#include <math.h>
#include <stdlib.h>

int main(int argc, char* argv[]) {
        double val = atof(argv[1]);
        printf("the log of %lf is %lf\n", val, log(val));
        return 0;
}
-----------------------
Compiled and executed with:
$ gcc -o logtest logtest.c -lm
$ ./logtest 32
the log of 32.000000 is 3.465736
$ valgrind --tool=callgrind ./logtest 32
==25013== Callgrind, a call-graph generating cache profiler
==25013== Copyright (C) 2002-2012, and GNU GPL'd, by Josef Weidendorfer et al.
==25013== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==25013== Command: ./logtest 32
==25013== 
==25013== For interactive control, run 'callgrind_control -h'.
vex amd64->IR: unhandled instruction bytes: 0xC4 0xE3 0xD9 0x6B 0x3D 0x4E 0x19 0x6
vex amd64->IR:   REX=0 REX.W=1 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=1 VEX.L=0 VEX.nVVVV=0x4 ESC=0F3A
vex amd64->IR:   PFX.66=1 PFX.F2=0 PFX.F3=0
==25013== valgrind: Unrecognised instruction at address 0x4c37a00.
==25013==    at 0x4C37A00: __ieee754_log_sse2 (in /lib64/libm-2.15.so)
==25013==    by 0x400674: main (in /home/jkingsley/foo/logtest)
==25013== Your program just tried to execute an instruction that Valgrind
==25013== did not recognise.  There are two possible reasons for this.
==25013== 1. Your program has a bug and erroneously jumped to a non-code
==25013==    location.  If you are running Memcheck and you just saw a
==25013==    warning about a bad jump, it's probably your program's fault.
==25013== 2. The instruction is legitimate but Valgrind doesn't handle it,
==25013==    i.e. it's Valgrind's fault.  If you think this is the case or
==25013==    you are not sure, please let us know and we'll try to fix it.
==25013== Either way, Valgrind will now raise a SIGILL signal which will
==25013== probably kill your program.
==25013== 
==25013== Process terminating with default action of signal 4 (SIGILL)
==25013==  Illegal opcode at address 0x4C37A00
==25013==    at 0x4C37A00: __ieee754_log_sse2 (in /lib64/libm-2.15.so)
==25013==    by 0x400674: main (in /home/jkingsley/foo/logtest)
==25013== 
==25013== Events    : Ir
==25013== Collected : 116873
==25013== 
==25013== I   refs:      116,873
Illegal instruction
------------------------
Other tools have the same issue.

I am running this on a AMD FX(tm)-8150, and libm would have been compiled with gcc 4.6.3  `-O2 -pipe -march=native -mtune=native`, which gives settings flags
$ gcc -c -Q -march=native --help=target
The following options are target specific:
  -m128bit-long-double        		[disabled]
  -m32                        		[disabled]
  -m3dnow                     		[disabled]
  -m3dnowa                    		[disabled]
  -m64                        		[enabled]
  -m80387                     		[enabled]
  -m8bit-idiv                 		[disabled]
  -m96bit-long-double         		[enabled]
  -mabi=                      		
  -mabm                       		[enabled]
  -maccumulate-outgoing-args  		[disabled]
  -maes                       		[enabled]
  -malign-double              		[disabled]
  -malign-functions=          		
  -malign-jumps=              		
  -malign-loops=              		
  -malign-stringops           		[enabled]
  -mandroid                   		[disabled]
  -march=                     		bdver1
  -masm=                      		
  -mavx                       		[enabled]
  -mavx256-split-unaligned-load 	[disabled]
  -mavx256-split-unaligned-store 	[disabled]
  -mbionic                    		[disabled]
  -mbmi                       		[disabled]
  -mbranch-cost=              		
  -mcld                       		[disabled]
  -mcmodel=                   		
  -mcpu=                      		
  -mcrc32                     		[disabled]
  -mcx16                      		[enabled]
  -mdispatch-scheduler        		[disabled]
  -mf16c                      		[disabled]
  -mfancy-math-387            		[enabled]
  -mfentry                    		[enabled]
  -mfma                       		[disabled]
  -mfma4                      		[enabled]
  -mforce-drap                		[disabled]
  -mfp-ret-in-387             		[enabled]
  -mfpmath=                   		
  -mfsgsbase                  		[disabled]
  -mfused-madd                		
  -mglibc                     		[enabled]
  -mhard-float                		[enabled]
  -mieee-fp                   		[enabled]
  -mincoming-stack-boundary=  		
  -minline-all-stringops      		[disabled]
  -minline-stringops-dynamically 	[disabled]
  -mintel-syntax              		
  -mlarge-data-threshold=     		
  -mlwp                       		[enabled]
  -mmmx                       		[disabled]
  -mmovbe                     		[disabled]
  -mms-bitfields              		[disabled]
  -mno-align-stringops        		[disabled]
  -mno-fancy-math-387         		[disabled]
  -mno-push-args              		[disabled]
  -mno-red-zone               		[disabled]
  -mno-sse4                   		[disabled]
  -momit-leaf-frame-pointer   		[disabled]
  -mpc                        		
  -mpclmul                    		[enabled]
  -mpopcnt                    		[enabled]
  -mprefer-avx128             		[disabled]
  -mpreferred-stack-boundary= 		
  -mpush-args                 		[enabled]
  -mrdrnd                     		[disabled]
  -mrecip                     		[disabled]
  -mred-zone                  		[enabled]
  -mregparm=                  		
  -mrtd                       		[disabled]
  -msahf                      		[enabled]
  -msoft-float                		[disabled]
  -msse                       		[enabled]
  -msse2                      		[enabled]
  -msse2avx                   		[disabled]
  -msse3                      		[enabled]
  -msse4                      		[enabled]
  -msse4.1                    		[enabled]
  -msse4.2                    		[enabled]
  -msse4a                     		[enabled]
  -msse5                      		
  -msseregparm                		[disabled]
  -mssse3                     		[enabled]
  -mstack-arg-probe           		[disabled]
  -mstackrealign              		[enabled]
  -mstringop-strategy=        		
  -mtbm                       		[disabled]
  -mtls-dialect=              		
  -mtls-direct-seg-refs       		[enabled]
  -mtune=                     		bdver1
  -muclibc                    		[disabled]
  -mveclibabi=                		
  -mvect8-ret-in-mem          		[disabled]
  -mvzeroupper                		[disabled]
  -mxop                       		[enabled]
---------------------

Any suggestions on fixing this?  I'm not entirely sure how I would go about making a valgrind-friendly libm, and don't really want to recompile my system without SSE just to do a bit of debugging...

Thanks,
James Kingsley

Re: [Valgrind-users] Request for ideas for Valgrind improvements (general or ARM)

[Konstantin T. <an...@ya...>]

06.08.2013, 08:23, "John Reiser" <jr...@Bi...>:
> Only two areas really matter:
> 1. speed of memcheck
> 2. 64-bit ARM
>
> The most likely path to better speed is to make cross-platform checking work.
> Check an ARM target program by running memcheck on a fast x86* CPU (>=4GHz)
> with a large data cache (>=8MB) under a "compatible" operating system.
> Translating system calls might be tedious but should not be onerous.

That would be quite useful not only for ARM, but for PPC and MIPS too.

-- 
Regards,
Konstantin

Re: [Valgrind-users] Request for ideas for Valgrind improvements (general or ARM)

[John R. <jr...@Bi...>]

Only two areas really matter:
1. speed of memcheck
2. 64-bit ARM

The most likely path to better speed is to make cross-platform checking work.
Check an ARM target program by running memcheck on a fast x86* CPU (>=4GHz)
with a large data cache (>=8MB) under a "compatible" operating system.
Translating system calls might be tedious but should not be onerous.

[Valgrind-users] Request for ideas for Valgrind improvements (general or ARM)

[Vasily G. <vas...@gm...>]

Hello, all.

I am searching some ideas for Valgrind's improvements where I can help. For
me, changes connected with ARM (or general, like speed improvements) are
quite interesting. I have some experience with Valgrind - implementation of
some instructions from ARM and Thumb instruction sets.

In fact, for me as ARM user, the main limiting factor for Valgrind is its
speed. Maybe it is possible somehow to increase it?

I have read articles about Valgrind (internal structure, shadow memory,
etc.). I have some ideas but I am not sure that they are good enough (and
speed improvements is not obvious). Here I placed the list of them:

1. Think about some new optimization during IR -> binary code conversion
after instrumentation. Maybe there are some new optimizations (see at LLVM
sources?) that can be implemented in Valgrind for speed? Some ARM-specific
optimizations?
2. Maybe we can slightly (introduce new flag?) increase memory consumption
but increase the speed? (increase cache size for compiled blocks?)
3. Now SETEND (feature of changing little\big endian) instruction for ARM
is not implemented. Maybe it is OK to implement it (big changes?) and
support big endianess for ARM? It will be also necessary to rewrite a lot
of instructions parsing in VEX.
4. Think about next ARM (v8 ?) and some new instructions\features that can
be realized?

In fact, if the project will be quite big\complex, I think I can ask a
couple of people to help with it. Any comments\ideas are welcome!

-- 
Thank you in advance,
Vasily