valgrind-users — General discussion list for Valgrind users

[Valgrind-users] Linux futexes in ARMv8 cause scaling issues?

[Karthik S. <ks...@dr...>]

Hi all,

I've run a few OpenMP-based multi-threaded applications with
Valgrind/Callgrind on an ARMv8-based server, and found that increasing the
number of threads has increased the per-thread IR, memory operations, and
integer operations, while floating point operations scaled correctly (as
displayed by the stats provided by Callgrind). In general, the native
behavior on the server is: increase the number of threads, reduce the
amount of memory ops, and instructions retired per thread, which I've
observed on the host machine's hardware counters.

On the documentation for Helgrind, I read that Linux futuxes may be causing
some quirky runtime behavior in Valgrind, so I recompiled gcc with linux
futexes disabled. I found that the per-thread IR, etc did indeed reduce,
but that tons of mutex locks were used for every barrier.

Does anyone know if this is the normal behavior? Is there a solution that
allows us to use the native run-time support library of GNU OpenMP when
using Valgrind-based tools?

For reference, I tested this with gcc 4.9.2 and Valgrind 3.10.1.

Thanks,

Karthik

Re: [Valgrind-users] Strange warning: Ignoring non-Dwarf2/3/4 block in .debug_info

[ISHIKAWA,chiaki <ish...@yk...>]

On 2016/01/18 23:32, Julian Seward wrote:
> Chiaki,
>
>> First of all, thank you for sharing this great package.
> First of all, thank you for supporting Thunderbird.  I use it all the time.
>
>> --11405-- WARNING: Serious error when reading debug info
>> --11405-- When reading debug info from
>> /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0.3200.3:
>> --11405-- Ignoring non-Dwarf2/3/4 block in .debug_info
> Hmm.  That is pretty strange.  Can you send by email (not to the
> list) a copy of this libgdk_pixbuf-2.0.so.0.3200.3, for investigation?
>
> J

Yes, I will.

Chiaki

Re: [Valgrind-users] ARMv8 Vectorized Double-precision Instructions

[Karthik S. <ks...@dr...>]

Hey Julian,

Looking back, I believe our toolset was actually using Valgrind 3.10.1.
I'll give Valgrind 3.11.0 a shot.

Thanks,

Karthik

On Mon, Jan 18, 2016 at 9:35 AM, Julian Seward <js...@ac...> wrote:

> On 27/10/15 12:02, Karthik Sangaiah wrote:
>
> >  405720: 4e60c508 fmaxnm v8.2d, v8.2d, v0.2d
>
> I'm pretty sure that's implemented.  Have you tried with 3.11.0?
> I suspect it fails because you are using an earlier version.
>
> J
>
>

Re: [Valgrind-users] ARMv8 Vectorized Double-precision Instructions

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

On 27/10/15 12:02, Karthik Sangaiah wrote:

>  405720: 4e60c508 fmaxnm v8.2d, v8.2d, v0.2d

I'm pretty sure that's implemented.  Have you tried with 3.11.0?
I suspect it fails because you are using an earlier version.

J

Re: [Valgrind-users] Strange warning: Ignoring non-Dwarf2/3/4 block in .debug_info

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

Chiaki,

> First of all, thank you for sharing this great package.

First of all, thank you for supporting Thunderbird.  I use it all the time.

> --11405-- WARNING: Serious error when reading debug info
> --11405-- When reading debug info from 
> /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0.3200.3:
> --11405-- Ignoring non-Dwarf2/3/4 block in .debug_info

Hmm.  That is pretty strange.  Can you send by email (not to the
list) a copy of this libgdk_pixbuf-2.0.so.0.3200.3, for investigation?

J

Re: [Valgrind-users] Information on adding unknown instructions due to "illegal opcde"?

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

> Is there any information on adding support for unsupported instructions?

Not really.  As John Reiser says, find an insn which is similar and use
that as an example.  The front ends (xx_to_IR.c) are highly repetitive
and you can usually find something fairly close to what you need.

That said, it would be useful to know what insn exactly you ran across.
What is implemented tends to cover the output of compilers in common use
plus many obscure instructions, but there are still corner cases not
implemented.  In particular for ARM there are instructions of the form

  reg1 = reg2 OP (reg3 rotated right by <bizarre constant>)

and they may not be implemented.  It's also interesting to know why
you fell across these; handwritten assembly, maybe?

Really the best fix for unimplemented instructions is to file a bug
report, and if you do fix it yourself, put the patch on the bug report.

J

Re: [Valgrind-users] valgrind on pandaboard

[Alina <ali...@ya...>]

nandhini chandramoorthy <nandhini.leo <at> gmail.com> writes:

> 
> 
> HiI tried the following 3 things : 1. I used Code Sourcery tool chain
(arm-none-linux-gnueabi-gcc) and changed $CC, $CPP, $CXX etc . Then I did
./configure --target=arm-none-linux-gnueabi --host=armv7-none-linux-gnueabi
--prefix=<installation-path> CFLAGS=-static
>  make
> make installThen I copied the installation directory to pandaboard. When I
type "valgrind --tool=cachegrind " I get "failed to start tool cachegrind
for platform 'arm-linux': permission denied."2. I have ubuntu 11.10
installed on the pandaboard. I used gcc toolchain to compile and install
valgrind on pandaboard directly and when I try to run it, i get the same
error message. 3. In all the Makefiles I changed options to cortex-a9. The
original switches are -marm -mcpu=cortex-a8. 
> I changed everything to -march=armv7 -mcpu=cortex-a9 -mfpu=neon. Then on
the PANDABOARD, I used gcc toolchain to compile and make. ./configure
--prefix=<installation-path> makeDuring make I get a number of warnings
"m-libassert.c warning : switch -mcpu=cortex-a9 conflicts with -march=armv7
switch [eabled by default] " Then make exited with an error (an assembler
message) Could you please tell me what mistake I am making ?On Sun, Mar 3,
2013 at 10:40 AM, Dan Kegel <dank <at> kegel.com> wrote:
> On Sun, Mar 3, 2013 at 7:21 AM, nandhini chandramoorthy
> <nandhini.leo <at> gmail.com> wrote:
> > I am trying to use valgrind to observe memory access patterns of certain
> > benchmarks on ARM core. I have a pandaboard with arm-cortexA9. On my x86
> > machine, i have sourcery codebench cross compilation tools installed. I
> > cross compiled valgrind  --
> > ./configure --target=arm-none-linux-gnueabi --host=armv7-none-linux-gnueabi
> > --prefix=<installation-path> CFLAGS=-static
> > make
> > make install
> >
> > Everything was fine. Then I copied the installation folder to my pandaboard.
> > When i try to run valgrind, i only get "cannot execute binary executable ".
> Which toolchain?
> (You're compiling the benchmarks and valgrind with the same toolchain, right?)
> What does 'file' say about the bad binary, and about good ones?- Dan
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> 
> _______________________________________________
> Valgrind-users mailing list
> Valgrind-users <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 

Hi,

How did you solve it? I have same issue.

Thank you!
Alina

[Valgrind-users] Strange warning: Ignoring non-Dwarf2/3/4 block in .debug_info

[ISHIKAWA,chiaki <ish...@yk...>]

Hi,

First of all, thank you for sharing this great package.

I encountered a strange bug (?) while trying to use valgrind to
validate the operation of a binary produced when I was testing Mozilla
Thunderbird operation.

The observation is with valgrind -3.12.0 SVN which was compiled last
November.  the copyright header shows this.

==11405== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==11405== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for 
copyright info

Now the problem.
As soon as the binary is run under valgrind, valgrind printed many 
warnings like the following.


--11405-- WARNING: Serious error when reading debug info
--11405-- When reading debug info from 
/usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0.3200.3:
--11405-- Ignoring non-Dwarf2/3/4 block in .debug_info
--11405-- WARNING: Serious error when reading debug info
--11405-- When reading debug info from 
/usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0.3200.3:
--11405-- Last block truncated in .debug_info; ignoring
--11405-- WARNING: Serious error when reading debug info
--11405-- When reading debug info from 
/usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0.3200.3:
--11405-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4
--11405-- WARNING: Serious error when reading debug info
--11405-- When reading debug info from 
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.4600.2:
--11405-- Ignoring non-Dwarf2/3/4 block in .debug_info
--11405-- WARNING: Serious error when reading debug info
--11405-- When reading debug info from 
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.4600.2:
--11405-- Last block truncated in .debug_info; ignoring
--11405-- WARNING: Serious error when reading debug info
--11405-- When reading debug info from 
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.4600.2:

           There are  more repetitions for different libraries

This is under Debian GNU/Linux 64-bit version.

uname -a outoup:
Linux ip030 3.19.5 #1 SMP Mon Apr 20 08:50:21 JST 2015 x86_64 GNU/Linux

Say, for the last library file in the warning lines, |file| command 
printed something like this.
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.4600.2: ELF 64-bit LSB shared 
object, x86-64, version 1 (SYSV), dynamically linked, 
BuildID[sha1]=f7cf7ddb040d36cb8709e6403bc19be4570754d6, stripped

Since I could link the binary using GNU LD (gold) without an obvious
issue to compile and build mozilla thunderbird locally under linux
64-bit on this PC, the library is not completely broken, I suppose.

Now using google and search for hits with the string "Ignoring
non-Dwarf2/3/4 block in .debug_info"
I immediately find a few hits:

The first one is about valgrind operation on ARM CPU.
http://sourceforge.net/p/valgrind/mailman/valgrind-users/thread/4E8...@bi.../
It mentions something about unaligned access.
But mine is x86_64 CPU and hugely popular one. Beside, I think x86 can 
read at any
octet boundary albeit minor performance loss if alignment is not perfect.
So I doubt anything like the ARM issue may exist. Correct ?

Second hit is from Feb 2015.
https://bugs.kde.org/show_bug.cgi?id=338781
which explains maybe "--read-var-info=yes" can be a problem (Is it on by 
default?)
and "--read-var-info=no" may solve the issue.
But it turns out it is an OSX issue. And maybe the compiler is from llvm.

The next three entries are from the same Debian bug entry.

Anyway, I tried to add --read-var-info=no, but it did not help.

The following is an excerpt from the log:
E.g.: Please understand that the invocation of valgrind is part of
a test harness and so I have to show the log line which showed how the
valgrind is invoked:

  0:01.09 PROCESS_OUTPUT: Thread-1 (pid:12190) Full command: 
['/usr/local/bin/valgrind', '--read-var-info=no', 
'--read-inline-info=no', 
'/NREF-COMM-CENTRAL/objdir-tb3/dist/bin/xpcshell', '-g', 
'/NREF-COMM-CENTRAL/objdir-tb3/dist/bin', '-a', 
'/NREF-COMM-CENTRAL/objdir-tb3/dist/bin', '-r', 
'/NREF-COMM-CENTRAL/objdir-tb3/dist/bin/components/httpd.manifest', 
'-m', '-s', '-e', 'const _HEAD_JS_PATH = 
"/NREF-COMM-CENTRAL/comm-central/mozilla/testing/xpcshell/head.js";', 
'-e', 'const _MOZINFO_JS_PATH = 
"/tmp/xpc-profile-fcjmuR/mozinfo.json";', '-e', 'const 
_TESTING_MODULES_DIR = 
"/NREF-COMM-CENTRAL/objdir-tb3/_tests/modules/";', '-f', 
'/NREF-COMM-CENTRAL/comm-central/mozilla/testing/xpcshell/head.js', 
'-p', '/tmp/xpc-plugins-wGKRGS', '-e', 'const _SERVER_ADDR = 
"localhost"', '-e', 'const _HEAD_FILES = [];', '-e', 'const _TAIL_FILES 
= [];', '-e', 'const _JSDEBUGGER_PORT = 0;', '-e', 'const _TEST_FILE = 
["/NREF-COMM-CENTRAL/objdir-tb3/_tests/xpcshell/caps/tests/unit/test_origin.js"];', 
'-e', 'const _TEST_NAME = "caps/tests/unit/test_origin.js"', '-e', 
'_execute_test(); quit(0);']
(pid:12190) "==12190== Memcheck, a memory error detector"
  0:01.09 PROCESS_OUTPUT: Thread-1 (pid:12190) "==12190== Copyright (C) 
2002-2015, and GNU GPL'd, by Julian Seward et al."
  0:01.09 PROCESS_OUTPUT: Thread-1 (pid:12190) "==12190== Using 
Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info"
  0:01.09 PROCESS_OUTPUT: Thread-1 (pid:12190) "==12190== Command: 
/NREF-COMM-CENTRAL/objdir-tb3/dist/bin/xpcshell -g 
/NREF-COMM-CENTRAL/objdir-tb3/dist/bin -a 
/NREF-COMM-CENTRAL/objdir-tb3/dist/bin -r 
/NREF-COMM-CENTRAL/objdir-tb3/dist/bin/components/httpd.manifest -m -s 
-e const\\ _HEAD_JS_PATH\\ =\\ 
"/NREF-COMM-CENTRAL/comm-central/mozilla/testing/xpcshell/head.js"; -e 
const\\ _MOZINFO_JS_PATH\\ =\\ "/tmp/xpc-profile-fcjmuR/mozinfo.json"; 
-e const\\ _TESTING_MODULES_DIR\\ =\\ 
"/NREF-COMM-CENTRAL/objdir-tb3/_tests/modules/"; -f 
/NREF-COMM-CENTRAL/comm-central/mozilla/testing/xpcshell/head.js -p 
/tmp/xpc-plugins-wGKRGS -e const\\ _SERVER_ADDR\\ =\\ "localhost" -e 
const\\ _HEAD_FILES\\ =\\ []; -e const\\ _TAIL_FILES\\ =\\ []; -e 
const\\ _JSDEBUGGER_PORT\\ =\\ 0; -e const\\ _TEST_FILE\\ =\\ 
["/NREF-COMM-CENTRAL/objdir-tb3/_tests/xpcshell/caps/tests/unit/test_origin.js"]; 
-e const\\ _TEST_NAME\\ =\\ "caps/tests/unit/test_origin.js" -e 
_execute_test();\\ quit(0);"
  0:01.09 PROCESS_OUTPUT: Thread-1 (pid:12190) "==12190== "
  0:10.66 PROCESS_OUTPUT: Thread-1 (pid:12190) "--12190-- WARNING: 
Serious error when reading debug info"
  0:10.66 PROCESS_OUTPUT: Thread-1 (pid:12190) "--12190-- When reading 
debug info from /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0.3200.3:"
  0:10.66 PROCESS_OUTPUT: Thread-1 (pid:12190) "--12190-- Ignoring 
non-Dwarf2/3/4 block in .debug_info"
  0:10.66 PROCESS_OUTPUT: Thread-1 (pid:12190) "--12190-- WARNING: 
Serious error when reading debug info"
  0:10.66 PROCESS_OUTPUT: Thread-1 (pid:12190) "--12190-- When reading 
debug info from /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0.3200.3:"
  0:10.66 PROCESS_OUTPUT: Thread-1 (pid:12190) "--12190-- Last block 
truncated in .debug_info; ignoring"
  0:10.68 PROCESS_OUTPUT: Thread-1 (pid:12190) "--12190-- WARNING: 
Serious error when reading debug info"

  ...


So it seems that the latest compiler/linker combination has produced the 
library
may not be producing library which valgrind expects to see.

What can I do to alert the GNU binutils and/or GCC people (does Debian 
use llvm compiler lately?) about this issue? And in what manner. I am 
not sure if I understand the cause of the issue completely.
All I can say is that the format is not compatible or something.
I can send the offending library on request.

Thank you in advance for your attention.

CI

Re: [Valgrind-users] Is Valgrind supported on ARM Cortex-M3?

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

On 01/12/2016 08:42 AM, Sean Condon wrote:
> Is Valgrind supported on ARM Cortex-M3?

No.  ARM Cortex-M3 supports only the ARMv7-M instruction set,
which has ONLY Thumb instructions (generally 16 bits each).
Valgrind requires full ARMv7 including ARM instructions (32 bits each);
the Thumb mode of full ARMv7 is supported, but only as an addition
to the ARM mode.

[Valgrind-users] Query on valkyrie

[kantheti p. <kan...@gm...>]

Hi Team,

>From the latest tar file provided on the valgrinds downloads page.

I have performed build and install.I could not find any binary vk_logmerge.

How to use vk_logmerge tool from the package.

If in case I am mailing to the wromg mail.
Could you please redirect me to the correct one.

Regards,
Prajyodh

Re: [Valgrind-users] Unrecognized Instruction in Ubuntu ARM library

[Jim S. <ji...@ji...>]

On 1/9/2016 7:11 PM, Tom Hughes wrote:
> On 09/01/16 22:34, Jim Starkey wrote:
>
>> Running Ubuntu/Mate on a Raspberry Pi 2, I get the following error:
>>
>>     disInstr(arm): unhandled instruction: 0xF1010200
>>                       cond=15(0xF) 27:20=16(0x10) 4:4=0 3:0=0(0x0)
>
> See https://bugs.kde.org/show_bug.cgi?id=322935 but the short version 
> is that the code has an insane "optimisation" that temporarily changes 
> the endianism of the processor and there's no way it's ever likely to 
> be supported in valgrind.
>
> I believe, from a brief examination when somebody hit this the other 
> day, that libarmmem is just optimised version of some routines like 
> memcpy that are already in the normal C library, so you can just drop 
> it and use the normal C library versions when valgrinding.
>

I appreciate the response.  It wasn't what I was hoping for, of course, 
but it beats spending a couple of days bashing my head against the wall.

Thanks.

[Valgrind-users] Is Valgrind supported on ARM Cortex-M3?

[Sean C. <sea...@po...>]

Is Valgrind supported on ARM Cortex-M3?

I'm trying to compile ValGrind for use with ucLinux on a Cortex-M3 using
a Code Sourcery toolchain.

I'm using a configure command like
./configure --host=arm-uclinuxeabi --build=x86_64-pc-linux-gnu
CLAGS="-mcpu=cortex-m3 -mthumb"
(in configure.in I clone the 'armv7*' to a 'arm' line)

It stops in m_trampoline.c with complaints like
m_trampoline.S: Assembler messages:
m_trampoline.S:594: Error: Thumb does not support conditional execution
m_trampoline.S:627: Error: lo register required -- `stmfd
sp!,{r4,r5,lr}'
m_trampoline.S:628: Error: instruction not supported in Thumb16 mode --
`subs lr,r2,#0'
m_trampoline.S:633: Error: dest must overlap one source register -- `add
r3,r0,lr'

Thanks in advance

Re: [Valgrind-users] Valgrind is broken on recent linux kernel

[Tom H. <to...@co...>]

On 11/01/16 08:29, Mike Krinkin wrote:

> recently i have faced the problem that valgrind fails to start on my
> linux amd64 laptop with the following error (specific mmap address may
> change depending on checked app, this one for simple "Hello, World"):
>
> valgrind: mmap(0x600000, 8192) failed in UME with error 12 (Cannot
> allocate memory).

Please open a ticket in bugzilla so we can track this.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

Re: [Valgrind-users] Valgrind is broken on recent linux kernel

[Mike K. <kri...@gm...>]

Hi,

recently i have faced the problem that valgrind fails to start on my
linux amd64 laptop with the following error (specific mmap address may
change depending on checked app, this one for simple "Hello, World"):
 
valgrind: mmap(0x600000, 8192) failed in UME with error 12 (Cannot
allocate memory).

I bisected linux kernel and found, that the problem is bacause of this
patch https://lkml.org/lkml/2015/12/14/72 . Patch classifies all memory
allocation (brk and mmap) in several groups and add checks against
respective rlimits. When memcheck-amd64-linux starts it set RLIMIT_DATA
to 0, but then it tries to mmap part of checked app binary with the
following call (reported by strace):

mmap(0x600000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0)

which fails, because PROT_WRITE MAP_PRIVATE mappings are now classified
as a data (and it sounds reasonable to me, because private writeable mmap
is essentialy an allocation), and therefore check agains RLIMIT_DATA
fails.

I don't know the logic behind setting RLIMIT_DATA to 0, but after i
commend out setrlimit call in the coregrind/m_main.c the problem was
gone. Is it a valgrind bug to assume that mmap isn't subject for
RLIMIT_DATA limit?

Re: [Valgrind-users] Unrecognized Instruction in Ubuntu ARM library

[Tom H. <to...@co...>]

On 09/01/16 22:34, Jim Starkey wrote:

> Running Ubuntu/Mate on a Raspberry Pi 2, I get the following error:
>
>     disInstr(arm): unhandled instruction: 0xF1010200
>                       cond=15(0xF) 27:20=16(0x10) 4:4=0 3:0=0(0x0)

See https://bugs.kde.org/show_bug.cgi?id=322935 but the short version is 
that the code has an insane "optimisation" that temporarily changes the 
endianism of the processor and there's no way it's ever likely to be 
supported in valgrind.

I believe, from a brief examination when somebody hit this the other 
day, that libarmmem is just optimised version of some routines like 
memcpy that are already in the normal C library, so you can just drop it 
and use the normal C library versions when valgrinding.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

Re: [Valgrind-users] Unrecognized Instruction in Ubuntu ARM library

[Jeffrey W. <nol...@gm...>]

On Sat, Jan 9, 2016 at 5:34 PM, Jim Starkey <ji...@ji...> wrote:
> Running Ubuntu/Mate on a Raspberry Pi 2, I get the following error:
>
> disInstr(arm): unhandled instruction: 0xF1010200
>                  cond=15(0xF) 27:20=16(0x10) 4:4=0 3:0=0(0x0)
> ==2462== valgrind: Unrecognised instruction at address 0x48596f4.
> ==2462==    at 0x48596F4: ??? (in /usr/lib/arm-linux-gnueabihf/libarmmem.so)
> ==2462== Your program just tried to execute an instruction that Valgrind
> ==2462== did not recognise.  There are two possible reasons for this.
> ==2462== 1. Your program has a bug and erroneously jumped to a non-code
> ==2462==    location.  If you are running Memcheck and you just saw a
> ==2462==    warning about a bad jump, it's probably your program's fault.
> ==2462== 2. The instruction is legitimate but Valgrind doesn't handle it,
> ==2462==    i.e. it's Valgrind's fault.  If you think this is the case or
> ==2462==    you are not sure, please let us know and we'll try to fix it.
> ==2462== Either way, Valgrind will now raise a SIGILL signal which will
> ==2462== probably kill your program.
> ==2462==
> ==2462== Process terminating with default action of signal 4 (SIGILL)
> ==2462==  Illegal opcode at address 0x48596F4
> ==2462==    at 0x48596F4: ??? (in /usr/lib/arm-linux-gnueabihf/libarmmem.so)
> ==2462==
>
> Any clue(s) would be appreciated.

I'm *guessing* you are using a downlevel Valgrind package like
debian-3.10.1-... You need Valgrind 3.11 for the most complete
ARM/ARM64 support.

Here's a Debian package that produced a similar finding on me earlier
today with a LeMaker HiKey (http://www.amazon.com/dp/B019O3QTSA):

    # apt-cache show valgrind
    Package: valgrind
    Version: 1:3.10.0-4
    Installed-Size: 49816
    Maintainer: Alessandro Ghedini <gh...@de...>
    Architecture: arm64
    Replaces: valgrind-dev
    ...

Jeff

[Valgrind-users] Unrecognized Instruction in Ubuntu ARM library

[Jim S. <ji...@ji...>]

Running Ubuntu/Mate on a Raspberry Pi 2, I get the following error:

    disInstr(arm): unhandled instruction: 0xF1010200
                      cond=15(0xF) 27:20=16(0x10) 4:4=0 3:0=0(0x0)
    ==2462== valgrind: Unrecognised instruction at address 0x48596f4.
    ==2462==    at 0x48596F4: ??? (in
    /usr/lib/arm-linux-gnueabihf/libarmmem.so)
    ==2462== Your program just tried to execute an instruction that Valgrind
    ==2462== did not recognise.  There are two possible reasons for this.
    ==2462== 1. Your program has a bug and erroneously jumped to a non-code
    ==2462==    location.  If you are running Memcheck and you just saw a
    ==2462==    warning about a bad jump, it's probably your program's
    fault.
    ==2462== 2. The instruction is legitimate but Valgrind doesn't
    handle it,
    ==2462==    i.e. it's Valgrind's fault.  If you think this is the
    case or
    ==2462==    you are not sure, please let us know and we'll try to
    fix it.
    ==2462== Either way, Valgrind will now raise a SIGILL signal which will
    ==2462== probably kill your program.
    ==2462==
    ==2462== Process terminating with default action of signal 4 (SIGILL)
    ==2462==  Illegal opcode at address 0x48596F4
    ==2462==    at 0x48596F4: ??? (in
    /usr/lib/arm-linux-gnueabihf/libarmmem.so)
    ==2462==

Any clue(s) would be appreciated.

Re: [Valgrind-users] Information on adding unknown instructions due to "illegal opcde"?

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

> Is there any information on adding support for unsupported instructions?

At this point, with >99% of instructions already recognized,
then you should reason by analogy.  Use a debugger such as gdb
to trace the execution under valgrind of a similar instruction,
then modify and extend to handle the unimplemented instruction.
For a 'rotate' instruction, use the corresponding right-shift.

Hints:
Assemble the two-line program
	_start: .globl _start
		.word <the-bits-for-your-instruction>
using
	gcc -nostartfiles  -nodefaultlibs  -nostdlib foo.S
to get an executable file with a .text that has 4==.p_memsz.
Then run memcheck on that executable.

Run "valgrind --help-debug" and look carefully at "Vex options
for all Valgrind tools", particularly --trace-flags.

Read "Debugging Valgrind with GDB" in README_DEVELOPERS.

The code is in VEX/priv/guest_arm*

Re: [Valgrind-users] Information on adding unknown instructions due to "illegal opcde"?

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

On Sat, 2016-01-09 at 07:02 -0500, Jeffrey Walton wrote:

> Is there any information on adding support for unsupported instructions?
Not that I know of.

The best is to read e.g. guest_arm_toIR.c and guest_arm64_toIR.c
and inspire from that. I think that usually, it is sufficient to
modify these files but sometimes, new IR instructions are needed,
or specific helpers have to be developed.

If you provide a patch, adding or modifying a test to cover
the new instruction helps to have your patch merged.

Philippe

Re: [Valgrind-users] x86 to VEX translation process

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

On Fri, 2016-01-08 at 15:35 -0700, Jon Stephens wrote:
> Hello all,
> I am a student at the University of Arizona doing research with Dr.
> Debray relating to computer security. We have been discussing a way to
> automatically generate taint propagation policies for a given x86
> instruction. This process would be similar to the translation process
> from x86 to VEX and so we were wondering if anyone could provide us
> with more information about how that was done. From what I understand
> from reading various papers on valgrind, each instruction in x86 is
> encoded using VEX micro-operations that represent the computation
> performed by that instruction.
Each x86 instruction is translated to IR instructions,
see guest_x86_toIR.c.
There is a guest_...._toIR.c for each arch (e.g. amd64, arm, arm64, 
...).

> If this is the case, was there some way of automating (or
> semi-automating) the process of creating the equivalent VEX
> operations, or were they all hand-written?
guest_...._toIR.c files are hand-written.

>  Additionally, in the VEX source code, is there a file that includes
> the VEX micro-operations that correlate with a given x86 instruction?
There is no 'table'. To know the mapping for an instruction, you must
read guest_x86_toIR.c.

You can also use the debug trace of valgrind to see how instructions
are translated from arch specific instructions to IR, then transformed
by the tool, then re-translated to the arch specific instructions.
See valgrind --help-debug describing the --trace-flags and related
options.
> 
> 
> Any information would be greatly appreciated,
> Jon Stephens
After reading the articles (see website), the best is to read the code.

Philippe

> 

[Valgrind-users] Information on adding unknown instructions due to "illegal opcde"?

[Jeffrey W. <nol...@gm...>]

Hi Everyone,

We use Valgrind as part of our release process. Its a security gate,
and the program must pass through it for release.

We recently ramped up testing on ARM and ARM64. We caught an illegal
opcode on both platforms. The illegal opcode related to a rotate,
which kind of surprised us. We have experienced it on occasion on
other platforms to, like x86_64 when GCC enlists SSE 4.2. Rather than
just filing the bug report, we would like to attempt to provide
support for the instruction. If the additional support is successful,
we would like to offer it back to the community.

We are having trouble locating information how to add instruction
support to Valgrind. For example, the following is not producing
useful results:
http://www.google.com/search?q="illegal+opcode"+site:valgrind.org .

Is there any information on adding support for unsupported instructions?

Thanks in advance.

[Valgrind-users] x86 to VEX translation process

[Jon S. <ste...@em...>]

Hello all,
I am a student at the University of Arizona doing research with Dr. Debray
relating to computer security. We have been discussing a way to
automatically generate taint propagation policies for a given x86
instruction. This process would be similar to the translation process from
x86 to VEX and so we were wondering if anyone could provide us with more
information about how that was done. From what I understand from reading
various papers on valgrind, each instruction in x86 is encoded using VEX
micro-operations that represent the computation performed by that
instruction. If this is the case, was there some way of automating (or
semi-automating) the process of creating the equivalent VEX operations, or
were they all hand-written? Additionally, in the VEX source code, is there
a file that includes the VEX micro-operations that correlate with a given
x86 instruction?

Any information would be greatly appreciated,
Jon Stephens

Re: [Valgrind-users] Support for Mac OSX 10.11 clarification

[Sean Au <xu...@gm...>]

Came across this blog:
http://oldpanda.net/2014/11/18/Install-Valgrind-on-Mac/ and after running
xcode-select --install, it worked.

Hope this helps someone else.

Cheers.

On Mon, Jan 4, 2016 at 1:35 PM, Sean McBride <se...@ro...>
wrote:

> On Sun, 3 Jan 2016 12:51:09 +0300, Konstantin Tokarev said:
>
> >03.01.2016, 02:32, "Sean Au" <xu...@gm...>:
> >> OS X 10.11 (El Capitan) does not allow user links in /usr/bin. It is
> >cleared from non-Apple things and is further locked down using some new
> >mechanism: I.e. not even root can put links there.
> >
> >Looks like a reasonable restriction, e.g. on FreeBSD all software
> >installed from ports goes into /usr/local prefix as well
>
> It also seems to have nothing to do with valgrind *working* or not, just
> an installation issue.
>
> Cheers,
>
> --
> ____________________________________________________________
> Sean McBride, B. Eng                 se...@ro...
> Rogue Research                        www.rogue-research.com
> Mac Software Developer              Montréal, Québec, Canada
>
>
>

Re: [Valgrind-users] Support for Mac OSX 10.11 clarification

[Sean M. <se...@ro...>]

On Sun, 3 Jan 2016 12:51:09 +0300, Konstantin Tokarev said:

>03.01.2016, 02:32, "Sean Au" <xu...@gm...>:
>> OS X 10.11 (El Capitan) does not allow user links in /usr/bin. It is
>cleared from non-Apple things and is further locked down using some new
>mechanism: I.e. not even root can put links there.
>
>Looks like a reasonable restriction, e.g. on FreeBSD all software
>installed from ports goes into /usr/local prefix as well

It also seems to have nothing to do with valgrind *working* or not, just an installation issue.

Cheers,

-- 
____________________________________________________________
Sean McBride, B. Eng                 se...@ro...
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montréal, Québec, Canada

Re: [Valgrind-users] Support for Mac OSX 10.11 clarification

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

03.01.2016, 02:32, "Sean Au" <xu...@gm...>:
> OS X 10.11 (El Capitan) does not allow user links in /usr/bin. It is cleared from non-Apple things and is further locked down using some new mechanism: I.e. not even root can put links there.

Looks like a reasonable restriction, e.g. on FreeBSD all software installed from ports goes into /usr/local prefix as well

-- 
Regards,
Konstantin