valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] valgrind breaks any long double operation on x86-64

[Lionel C. <lio...@gm...>]

On 29 January 2014 21:54, Tina Harriott <tin...@gm...> wrote:
> On 22 January 2014 22:36, Philippe Waroquiers
> <phi...@sk...> wrote:
>> On Wed, 2014-01-22 at 00:19 +0100, Lionel Cons wrote:
>>> On 22 January 2014 00:03, Tom Hughes <to...@co...> wrote:
>>> > On 21/01/14 21:49, Tina Harriott wrote:
>>> >
>>> >> I am new to this list. Can anyone guide me dissect a problem with
>>> >> valgrinds long double fp math on x86-64 cpus? We're getting major
>>> >> malfunctions in our applications because any long double operation
>>> >> (say y=sinl(x)) contains rubbish in the least significant bits.
>>> >
>>> > See the "Limitations" section of the manual:
>>> >
>>> >    http://www.valgrind.org/docs/manual/manual-core.html#manual-core.limits
>>> >
>>> > Specifically the section about floating point limitations.
>>>
>>> "...Whether or not this is critical remains to be seen..."
>>>
>>> Yeah, that comment is so 'funny' that it hurts again. The difference
>>> between 64bit math and 80bit math is whether a MBDA Meteor missile
>>> will hit its target or not (Michael Östergren holds a personal grudge
>>> against valgrind because of weeks lost due this particular
>>> embarrassing bug screwing up simulations btw), whether the beams in
>>> LHC will meet the (intended!) target or not, whether math in SAS
>>> software works or not (warranting a warning in the written
>>> documentation that running with valgrind to test 3rd party plugins is
>>> not supported). So the list of things which do *NOT* work with
>>> valgrind is *impressive* and hurt high value projects, IMHO warranting
>>> at least the removal of that mocking comment "...Whether or not this
>>> is critical remains to be seen...". Please.
>> Effectively, it looks clear that many applications have problems
>> with this aspect. Would be better to rephrase the doc :).
>>
>> Now, maybe these applications should better be compilable
>> with 64 bits floats, and would/should then work properly natively
>> and under valgrind.
>>
>> The gcc documentation says for -mfpmath=sse:
>>
>>   The resulting code should be considerably faster in the majority of
>>   cases and avoid the numerical instability problems of 387 code, but
>>   may break some existing code that expects temporaries to be 80
>>   bits.
>>
>> So, you might try to compile your app with the above flag
>> (I guess you might need a #ifdef or so to have a typedef that
>> is 80 bits without the above, and 64 bits with the above).
>>
>> But of course, we all agree it would be nice to have 80 bits floats
>> properly supported by Valgrind. It is just nobody has time/money/effort
>> to spend on that :(.
>
> Kickstarter project maybe?

Philippe?


>
> Tina
> --
> Tina Harriott  - Women in Mathematics
> Contact: tin...@gm...

Lionel

Re: [Valgrind-users] Callgrind: where do I find the list of event names?

[Dallman, J. <joh...@si...>]

> I have a lot of calls to functions with names that I recognise,
> but which have a '2 appended to their names. These don't exist
> in the source: any idea what they signify?

They're in the callgrind documentation; they're about recursion, and
I clearly need to accumulate their call counts into those for the basic
function.

Thanks, Julian.

--
John Dallman
-----------------
Siemens Industry Software Limited is a limited company registered in England and Wales.
Registered number: 3476850.
Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD.

Re: [Valgrind-users] Callgrind: where do I find the list of event names?

[Dallman, J. <joh...@si...>]

Philippe Waroquiers <phi...@sk...> wrote:

> Starting callgrind with default options, and then using
> kcachegrind on the resulting callgrind.out file, kcachegrind
> shows the nr of calls to the functions.

I'm trying to avoid using kcachegrind, because I need to automate
this process. We have tens of thousands of test cases we'll want
to feed through this and requiring human interaction is thus bad.

Josef Weidendorfer [mailto:Jos...@gm...] wrote:

> Yes. Call counts are special.

Aha.

> --tree=caller shows the callers of each function, with the call
> count in parenthesis.

Yup, and that output looks a lot easier to parse than the full
callgrind output. I have something odd in the output, though:
I have a lot of calls to functions with names that I recognise,
but which have a '2 appended to their names. These don't exist
in the source: any idea what they signify?

8,658,501  < ???:read__list'2 (5826x) [kid.out]
128,976,260  < ???:read_sub_list'2 (158404x) [kid.out]
2,107  < ???:relax'2 (43x) [kid.out]
2,416,508  < ???:REL_gen_external'2 (437x) [kid.out]

> Hmm. It should be easy to show the summed up call count for each
> function also without callers/callee display.

That would be nice if it could be added easily.

thanks, everyone,

--
John Dallman

-----------------
Siemens Industry Software Limited is a limited company registered in England and Wales.
Registered number: 3476850.
Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD.

[Valgrind-users] Compiling with custom mips toolchain

[Chris P. <jud...@gm...>]

Hi,

At $dayjob we maintain our own cross-toolchains (mostly plucked from
gentoo linux). Out mips compiler ends up named
"mipsbe-softfloat-linux-gnu" which fails the supported CPU test based
on $host_cpu. I'm not sure how common the mipsbe thing is but I found
a few references to it on various gcc mailing lists so I assume we're
not the only ones.

So here's a patch to update the configure test. Actually I thought by
putting the mips64 stuff first we can collapse the mips32 tests into a
single wildcard match. Both approaches fix my problem but the 2nd one
is affects more platforms so might be a little more contentious.

I'm posting this here because I didn't want to create an account on
kde.org just to report a bug for which I already had a fix for. If you
really a bugzilla report raised let me know.

Cheers,
Chris

Re: [Valgrind-users] Callgrind: where do I find the list of event names?

[Josef W. <Jos...@gm...>]

Am 12.02.2014 19:03, schrieb Philippe Waroquiers:
> On Wed, 2014-02-12 at 17:00 +0000, Dallman, John wrote:
>> That doesn't look as if there are any other events present, unless
>> they're
>> called something different. I realise I've jumped to the conclusion
>> that
>> calls are events, and this might not be true.

Yes. Call counts are special.
All "regular" events are listed after "events:" in the header
of callgrind.out.

>> I guess I can write something to digest the .out file and produce call
>> counts from it. 
> Starting callgrind with default options,
> and then using kcachegrind on the resulting callgrind.out file,
> kcachegrind shows the nr of calls to the functions.
> 
> callgrind_annotate --tree=both
> seems also to give the nr of calls.

--tree=caller shows the callers of each function, with the call count
in parenthesis.

Hmm. It should be easy to show the summed up call count for each
function also without callers/callee display.

Josef


> 
> Philippe
> 
> 
> 
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience.  Start now.
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 

Re: [Valgrind-users] Callgrind: where do I find the list of event names?

[Josef W. <Jos...@gm...>]

Am 12.02.2014 14:52, schrieb Dallman, John:
> I'm looking at using callgrind to replace an expensive Windows coverage tool,
> and for some other work where the ideas are only part-formed.
> 
> The default callgrind run and callgrind_annonate display shows Ir events, but
> I only need to count function entries. Is there a way to only collect those
> and have callgrind run faster??

As Julian said, it does not get faster by not collecting Ir events, as
without cache simulation, callgrind only counts how often basic blocks
where executed.
The important task of callgrind is to increment counters for
(caller site/called function) tuples, to build the call graph.
This often involves hash table lookups.

If you are only interested in call counts of functions, a specific tool
for that may be a lot faster: just increment a counter whenever a basic
block is executed that represents a function entry.

> callgrind_annotate has the --show option to only show specific events, but I
> can't find a list of event names to feed it. Where should I be looking?

Julian is right: callgrind_annotate just takes it from the callgrind
output. Events for "--show" are events that always can be related to
some code. In contrast to that, call counts relate to (from,to) tuples
of code positions, and are handled special: they have no specific name.

E.g. do a grep for "Ir" in the callgrind directory, and you will
see the string "Ir" in sim.c. Depending on the mode callgrind is
running in, different sets of event names are registered.

Josef

> To explain a bit, the reason I only need function entries is that we collect
> coverage data on a per-function basis, for all our test cases, and then use
> that to discover which test cases we need to run for changes to a given set
> of functions.
> 
> The other task consists of trying to find the most-called functions, because
> on a different platform, I am having to use a compiler option that adds a
> small constant overhead to some, but not all, functions. If I can discover
> the most-called functions, I can then find out if they are having the overhead
> added by the compiler, and then try to revise them so that the compiler no
> longer needs to do that.
> 
> thanks,
> 
> --
> John Dallman
> 
> -----------------
> Siemens Industry Software Limited is a limited company registered in England and Wales.
> Registered number: 3476850.
> Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD.
> 
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience.  Start now.
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 

Re: [Valgrind-users] Callgrind: where do I find the list of event names?

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

On Wed, 2014-02-12 at 17:00 +0000, Dallman, John wrote:
> That doesn't look as if there are any other events present, unless
> they're
> called something different. I realise I've jumped to the conclusion
> that
> calls are events, and this might not be true.
> 
> I guess I can write something to digest the .out file and produce call
> counts from it. 
Starting callgrind with default options,
and then using kcachegrind on the resulting callgrind.out file,
kcachegrind shows the nr of calls to the functions.

callgrind_annotate --tree=both
seems also to give the nr of calls.

Philippe

Re: [Valgrind-users] Callgrind: where do I find the list of event names?

[Dallman, J. <joh...@si...>]

Julian Seward wrote:

> I suspect not.  In any case counting insns is not terribly expensive,
> so the gain you'd get would be modest.

OK.

> I suspect the names are present in the callgrind.out file, and so
> callgrind_annotate just slices out those that you list.  It doesn't
> itself know the names.  But what part of the .c files of callgrind
> generates the names, I have no idea.

The only usage of the word "event" in the callgrind.out file, apart from
the names of functions that happen to include "event", is in the header:

$ more callgrind.out.xyz
version: 1
creator: callgrind-3.8.1
pid: 7926
cmd:  xxxx.xxx
part: 1

desc: I1 cache:
desc: D1 cache:
desc: LL cache:

desc: Timerange: Basic block 0 - 699103124
desc: Trigger: Program termination

positions: line
events: Ir
summary: 4496324814

ob=(2) ???
fl=(2) ???
fn=(302) 0x00000000053fecd8
0 2
cob=(8) /lib64/libdl-2.11.1.so
cfi=(8) ???
cfn=(304) 0x0000000000000df0
calls=1 0
...


That doesn't look as if there are any other events present, unless they're
called something different. I realise I've jumped to the conclusion that
calls are events, and this might not be true.

I guess I can write something to digest the .out file and produce call
counts from it.

thanks,

--
John Dallman

-----------------
Siemens Industry Software Limited is a limited company registered in England and Wales.
Registered number: 3476850.
Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD.

Re: [Valgrind-users] Callgrind: where do I find the list of event names?

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

(guessing at both questions; JosefW would know for definite)

> The default callgrind run and callgrind_annonate display shows Ir events, but
> I only need to count function entries. Is there a way to only collect those
> and have callgrind run faster??

I suspect not.  In any case counting insns is not terribly expensive, so the
gain you'd get would be modest.

> callgrind_annotate has the --show option to only show specific events, but I
> can't find a list of event names to feed it. Where should I be looking?

I suspect the names are present in the callgrind.out file, and so
callgrind_annotate just slices out those that you list.  It doesn't
itself know the names.  But what part of the .c files of callgrind
generates the names, I have no idea.

J

[Valgrind-users] Callgrind: where do I find the list of event names?

[Dallman, J. <joh...@si...>]

I'm looking at using callgrind to replace an expensive Windows coverage tool,
and for some other work where the ideas are only part-formed.

The default callgrind run and callgrind_annonate display shows Ir events, but
I only need to count function entries. Is there a way to only collect those
and have callgrind run faster??

callgrind_annotate has the --show option to only show specific events, but I
can't find a list of event names to feed it. Where should I be looking?

To explain a bit, the reason I only need function entries is that we collect
coverage data on a per-function basis, for all our test cases, and then use
that to discover which test cases we need to run for changes to a given set
of functions.

The other task consists of trying to find the most-called functions, because
on a different platform, I am having to use a compiler option that adds a
small constant overhead to some, but not all, functions. If I can discover
the most-called functions, I can then find out if they are having the overhead
added by the compiler, and then try to revise them so that the compiler no
longer needs to do that.

thanks,

--
John Dallman

-----------------
Siemens Industry Software Limited is a limited company registered in England and Wales.
Registered number: 3476850.
Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD.

Re: [Valgrind-users] Memcheck in Valgrind 3.8.1 hanging

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

On Tue, 2014-02-11 at 07:22 +0000, David Carter wrote:
> Hi Philippe, 
> 
> Thanks for your suggestions, I have got the first part of the
> information.  It seems there is some contention over locale
> resources.  Do you agree?   
Well, difficult to say without looking more in depth at the code.
Taking into account that there are threads still running,
that the valgrind trace shows that threads are being scheduled,
I guess the problem is linked to the application, not to valgrind.

It looks to me that the easiest would be to have a way to
debug the application, trying e.g. a newer gdb and vgdb
(if the newer gdb supports the strange executable format).

Alternatively, just make a normal executable :).

At this stage, not much can be done from Valgrind side I am afraid.


Philippe

[Valgrind-users] Valgrind on ARM V6 - freescale imx35 (ARM1136)

[Kalkere, Giridhara(IE10) <Gir...@Ho...>]

Hello,

Warm Greetings...!
I am new to this mailing list.

I am trying to use the valgrind with ARM1136 which is ARM V6 processor running linux 2.6.31 and I couldn't able to compile it for this target.
I googled for half a day and found lots of people are facing similar issues. They couldnot able to use it with ARM V6.

I would be great if anybody can write what's the problem behind using it on ARM V6.

Thanks and Regards,
Giri

Re: [Valgrind-users] Incorrect results from inline assembly when running under Valgrind

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

On 11/02/14 09:45, Jeffrey Walton wrote:
> On Tue, Feb 11, 2014 at 4:11 AM, Tom Hughes <to...@co...> wrote:
>> On 11/02/14 08:38, Jeffrey Walton wrote:
>>
>>> Perhpas a --cpu=XXX switch would be helpful for switching between
>>> cpu's. (Forgive me if its non-trivial to do. I know nothing about
>>> Valgrind architecture or operation. I just know a bit about using it
>>> to hunt leaks).
>>
>>
>> There's no point us allowing you to request a CPUID that reports RDRAND
>> support if valgrind is going to bomb out with an unsupported instruction
>> error as soon as you try and execute it.

> RDRAND is easy - back it with /dev/urand.

I wasn't saying it couldn't be implemented, just that it's not as simple 
as just changing what CPUID reports, which seemed to be what you were 
suggesting.

If we supported RDRAND then we would just announce it in CPUID and you 
wouldn't need a --cpu flag.

> AES-NI seems to be the difficult one, and I'm surprised Valgrind
> reports its supported.

It's probably done via a helper so it effectively gets passed through.

Tom

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

Re: [Valgrind-users] Incorrect results from inline assembly when running under Valgrind

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

On Tue, Feb 11, 2014 at 4:11 AM, Tom Hughes <to...@co...> wrote:
> On 11/02/14 08:38, Jeffrey Walton wrote:
>
>> Perhpas a --cpu=XXX switch would be helpful for switching between
>> cpu's. (Forgive me if its non-trivial to do. I know nothing about
>> Valgrind architecture or operation. I just know a bit about using it
>> to hunt leaks).
>
>
> There's no point us allowing you to request a CPUID that reports RDRAND
> support if valgrind is going to bomb out with an unsupported instruction
> error as soon as you try and execute it.
>
RDRAND is easy - back it with /dev/urand.

AES-NI seems to be the difficult one, and I'm surprised Valgrind
reports its supported.

Jeff

Re: [Valgrind-users] Incorrect results from inline assembly when running under Valgrind

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

On 11/02/14 08:38, Jeffrey Walton wrote:

> Perhpas a --cpu=XXX switch would be helpful for switching between
> cpu's. (Forgive me if its non-trivial to do. I know nothing about
> Valgrind architecture or operation. I just know a bit about using it
> to hunt leaks).

There's no point us allowing you to request a CPUID that reports RDRAND 
support if valgrind is going to bomb out with an unsupported instruction 
error as soon as you try and execute it.

Tom

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

Re: [Valgrind-users] Incorrect results from inline assembly when running under Valgrind

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

Thanks John.

> A quick search of the web for "valgrind CPUID" will fill in the details.
For https://bugs.kde.org/show_bug.cgi?id=155528, does Valgrind want
the output for an i5 so it can fake an i5? I use Ivy Bridge i5's
specifically for AES-NI and RDRAND.

Perhpas a --cpu=XXX switch would be helpful for switching between
cpu's. (Forgive me if its non-trivial to do. I know nothing about
Valgrind architecture or operation. I just know a bit about using it
to hunt leaks).

Jeff

On Mon, Feb 10, 2014 at 10:43 PM, John Reiser <jr...@bi...> wrote:
> On 02/10/2014 03:35 PM, Jeffrey Walton wrote:
>> I've got some code that determines CPU capabilities for x86
>> processors. I'm interested in RDRAND and AESNI, and I use three
>> functions to determine the capabilities: HasIntel(), HasAESNI() and
>> HasRDRAND().
>>
>> Debug configurations compiled with GCC and Clang work fine. Release
>> configuration compiled with GCC and Clang work fine.
>>
>> However, I get *one* incorrect result when running under Valgrind. The
>> incorrect result is from HasRDRAND(). Under Valgrind, the result is 0,
>> which means RDRAND is not available.
>
> Valgrind deliberately "fakes" the results of CPUID so that the bits
> reflect the virtual machine that valgrind knows how to support.
> Valgrind does not know how to implement RDRAND.
> [Only Intel and very few others know *exactly* what RDRAND does.]
> A quick search of the web for "valgrind CPUID" will fill in the details.
> It's even documented: search for 'CPUID' or 'SSE2' in and below
> the docs/ directory of the source tree.
>

[Valgrind-users] Endless loop happen when using lackey with --trace-mem=yes on ARM

[jianan hu <huj...@gm...>]

Hi everyone,

I tried to use lackey to record every memory access made by program. I
wrote very simple Hello Word program and used lackey to trace.
Unfortunately, lackey couldn't finish this job and I got very huge log file
(>100M) so I had to stop it.

After checked log file, lackey recorded a lot of following repeat
information:
I  04853198,2
I  0485319a,2
I  0485319c,4
 S 0490c0bc,4
I  048531a0,4
I  048531a4,2
I  04853194,4
 L 0490c0bc,4
I  04853198,2
I  0485319a,2
I  0485319c,4
 S 0490c0bc,4
I  048531a0,4
I  048531a4,2
I  04853194,4
 L 0490c0bc,4

My environment:
uname -r : 3.9.0-1-linaro-omap
Pandaboard ES, I also checked on OMAP 5432 Evm Board.


Steps to Reproduce:
Setp 1. Write test.c
#include <stdio.h>
int main()
{
    printf("Hello\n");
    return 0;
}

Step 2. Compile program.
    arm-linux-gnueabihf-gcc ./test.c

Step 3. valgrind --log-file="log.txt" --tool=lackey --trace-mem=yes ./a.out



After checked the code (lk_main.c), I found that the problem may be dirty
helper. I only call addStmtToIRSB when "ev->addr->tag" is "Iex_RdTmp",
Endless loop never happens.

I modified the "addStmtToIRSB( sb, IRStmt_Dirty(di) );" (in flushEvents
function) code into following codes:

      switch (ev->addr->tag) {
      case Iex_Const:
           VG_(printf)("L %08lx\n", ev->addr->Iex.Const.con->Ico.U32);
           break;
      case Iex_RdTmp:
           addStmtToIRSB( sb, IRStmt_Dirty(di) );
           VG_(printf)("Iex_RdTmp %lu\n", ev->addr->Iex.RdTmp.tmp);
           break;
      }


Does anyone can help me? Thanks!

Best Regards.

Re: [Valgrind-users] Incorrect results from inline assembly when running under Valgrind

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

On 02/10/2014 03:35 PM, Jeffrey Walton wrote:
> I've got some code that determines CPU capabilities for x86
> processors. I'm interested in RDRAND and AESNI, and I use three
> functions to determine the capabilities: HasIntel(), HasAESNI() and
> HasRDRAND().
> 
> Debug configurations compiled with GCC and Clang work fine. Release
> configuration compiled with GCC and Clang work fine.
> 
> However, I get *one* incorrect result when running under Valgrind. The
> incorrect result is from HasRDRAND(). Under Valgrind, the result is 0,
> which means RDRAND is not available.

Valgrind deliberately "fakes" the results of CPUID so that the bits
reflect the virtual machine that valgrind knows how to support.
Valgrind does not know how to implement RDRAND.
[Only Intel and very few others know *exactly* what RDRAND does.]
A quick search of the web for "valgrind CPUID" will fill in the details.
It's even documented: search for 'CPUID' or 'SSE2' in and below
the docs/ directory of the source tree.

-- 

[Valgrind-users] Incorrect results from inline assembly when running under Valgrind

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

I've got some code that determines CPU capabilities for x86
processors. I'm interested in RDRAND and AESNI, and I use three
functions to determine the capabilities: HasIntel(), HasAESNI() and
HasRDRAND().

Debug configurations compiled with GCC and Clang work fine. Release
configuration compiled with GCC and Clang work fine.

However, I get *one* incorrect result when running under Valgrind. The
incorrect result is from HasRDRAND(). Under Valgrind, the result is 0,
which means RDRAND is not available.

I think its related to "Valgrind shows different results for ubuntu
and debian x86 cpuid implementations",
http://sourceforge.net/mailarchive/message.php?msg_id=31873412.

Can anyone confirm this is related to VEX virtual machine? I want to
ensure I'm not seeing success in Debug and Release by dumb-luck (and
possibly have an unforeseen problem to fix).

Thanks in advance.

**********
# Debian 7.3, x64, fully patched
$ uname -a
Linux debian-q500 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux

# Built from sources a couple of weeks ago
$ valgrind --version
valgrind-3.9.0

**********

static void get_cpuid_info(CPUIDinfo *info, const unsigned int func,
const unsigned int subfunc)
{
    LogDebug("get_cpuid_info");

    UNUSED(info); UNUSED(func); UNUSED(subfunc);

    __asm__ __volatile__ (
        "cpuid"
        : "=a"(info->EAX), "=b"(info->EBX), "=c"(info->ECX), "=d"(info->EDX)
        : "a"(func), "c"(subfunc)
    );
}

int HasIntel()
{
    static int intel_cpu = 0;
    static once_flag flag;

    call_once(flag, []()
    {
        CPUIDinfo info;
        get_cpuid_info(&info,0,0);
        if(memcmp((char *)(&info.EBX), "Genu", 4) == 0 &&
            memcmp((char *)(&info.EDX), "ineI", 4) == 0 &&
            memcmp((char *)(&info.ECX), "ntel", 4) == 0) {
                intel_cpu = 1;
        }
    });

    return intel_cpu;
}

int HasRDRAND()
{
    static volatile int has_rdrand = 0;
    static once_flag flag;

    call_once(flag, []()
    {
        if(HasIntel())
        {
            CPUIDinfo info;
            static const unsigned int RDRAND_CAP_BIT = (1 << 30);
            AC_ASSERT(0x40000000 == RDRAND_CAP_BIT);

            get_cpuid_info(&info,1,0);
            if ((info.ECX & RDRAND_CAP_BIT)==RDRAND_CAP_BIT)
                has_rdrand = 1;
        }
    });

    return has_rdrand;
}

int HasAESNI()
{
    static volatile int has_aesni = 0;
    static once_flag flag;

    call_once(flag, []()
    {
        if(HasIntel())
        {
            CPUIDinfo info;
            static const unsigned int AESNI_CAP_BIT = (1 << 25);
            AC_ASSERT(0x2000000 == AESNI_CAP_BIT);

            get_cpuid_info(&info,1,0);
            if ((info.ECX & AESNI_CAP_BIT)==AESNI_CAP_BIT)
                has_aesni = 1;
        }
    });

    return has_aesni;
}

Re: [Valgrind-users] Intel i3 vs.Intel I7 - unhandled instruction bytes: 0xC4 0xC2 0x79 0xF7 0xC9 0x89 0x45 0x80

[Christoph N. <nie...@hl...>]

Hello,

For gcc you may have a look onto the -march and -mtune options in the man pages to restrict the generated instruction set to an older CPU type.
Your i7 may be detected as corei7-avx while your i3 may be detected as an older type.

There are also a lot of options to selectively disable specific features, e.g. -mno-avx2, -mno-sse4.2, ... in the man pages.

Regards
Christoph Niethammer

--

Christoph Niethammer
High Performance Computing Center Stuttgart (HLRS)
Nobelstrasse 19
70569 Stuttgart

Tel: ++49(0)711-685-87203
email: nie...@hl...
http://www.hlrs.de/people/niethammer




----- Ursprüngliche Mail -----
Von: "Brian Budge" <bri...@gm...>
An: "Adam.Jirasek" <ada...@gm...>
CC: val...@li...
Gesendet: Freitag, 7. Februar 2014 23:43:11
Betreff: Re: [Valgrind-users] Intel i3 vs.Intel I7 - unhandled instruction bytes: 0xC4 0xC2 0x79 0xF7 0xC9 0x89 0x45 0x80

On Fri, Feb 7, 2014 at 3:28 PM, Adam.Jirasek <ada...@gm...> wrote:
> Hello
>
> I have a C program which I routinely test with valgrind.
> The platform is Intel i3 dual core, gcc-4.7.3. and for all my tests
> valgrind did not give any warning when I started my program
>
>
> Now I updated to a new computer
> Intel i7 4th generation, gcc-4.7.3 and when I start valgrind with my
> code I get:
>
> valgrind --tool=memcheck  --trace-children=yes
> --vex-iropt-register-updates=allregs-at-mem-access --leak-check=full
> --leak-resolution=high --show-reachable=yes  --track-origins=yes
> ../../Source/Server_Main.out --port 31000 --input_file
> Definition_File_PDT_Modes  --show
> ==28771== Memcheck, a memory error detector
> ==28771== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
> ==28771== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
> ==28771== Command: ../../Source/Server_Main.out --port 31000
> --input_file Definition_File_PDT_Modes --show
> ==28771==
> vex amd64->IR: unhandled instruction bytes: 0xC4 0xC2 0x79 0xF7 0xC9
> 0x89 0x45 0x80
> vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=1
> vex amd64->IR:   VEX=1 VEX.L=0 VEX.nVVVV=0x0 ESC=0F38
> vex amd64->IR:   PFX.66=1 PFX.F2=0 PFX.F3=0
> ==28771== valgrind: Unrecognised instruction at address 0x400da4b.
> ==28771==    at 0x400DA4B: _dl_important_hwcaps (in /lib64/ld-2.17.so)
> ==28771==    by 0x4007D8E: _dl_init_paths (in /lib64/ld-2.17.so)
> ==28771==    by 0x4003128: dl_main (in /lib64/ld-2.17.so)
> ==28771==    by 0x40152E7: _dl_sysdep_start (in /lib64/ld-2.17.so)
> ==28771==    by 0x4004EA4: _dl_start (in /lib64/ld-2.17.so)
> ==28771==    by 0x4001647: ??? (in /lib64/ld-2.17.so)
> ==28771==    by 0x5: ???
> ==28771==    by 0x7FF000056: ???
> ==28771==    by 0x7FF000073: ???
> ==28771==    by 0x7FF00007A: ???
> ==28771==    by 0x7FF000080: ???
> ==28771==    by 0x7FF00008D: ???
> ==28771== Your program just tried to execute an instruction that Valgrind
> ==28771== did not recognise.  There are two possible reasons for this.
> ==28771== 1. Your program has a bug and erroneously jumped to a non-code
> ==28771==    location.  If you are running Memcheck and you just saw a
> ==28771==    warning about a bad jump, it's probably your program's fault.
> ==28771== 2. The instruction is legitimate but Valgrind doesn't handle it,
> ==28771==    i.e. it's Valgrind's fault.  If you think this is the case or
> ==28771==    you are not sure, please let us know and we'll try to fix it.
> ==28771== Either way, Valgrind will now raise a SIGILL signal which will
> ==28771== probably kill your program.
> ==28771==
> ==28771== Process terminating with default action of signal 4 (SIGILL)
> ==28771==  Illegal opcode at address 0x400DA4B
> ==28771==    at 0x400DA4B: _dl_important_hwcaps (in /lib64/ld-2.17.so)
> ==28771==    by 0x4007D8E: _dl_init_paths (in /lib64/ld-2.17.so)
> ==28771==    by 0x4003128: dl_main (in /lib64/ld-2.17.so)
> ==28771==    by 0x40152E7: _dl_sysdep_start (in /lib64/ld-2.17.so)
> ==28771==    by 0x4004EA4: _dl_start (in /lib64/ld-2.17.so)
> ==28771==    by 0x4001647: ??? (in /lib64/ld-2.17.so)
> ==28771==    by 0x5: ???
> ==28771==    by 0x7FF000056: ???
> ==28771==    by 0x7FF000073: ???
> ==28771==    by 0x7FF00007A: ???
> ==28771==    by 0x7FF000080: ???
> ==28771==    by 0x7FF00008D: ???
> ==28771==
> ==28771== HEAP SUMMARY:
> ==28771==     in use at exit: 0 bytes in 0 blocks
> ==28771==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
> ==28771==
> ==28771== All heap blocks were freed -- no leaks are possible
> ==28771==
> ==28771== For counts of detected and suppressed errors, rerun with: -v
> ==28771== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
> Illegal instruction
>
>
>
> Any advice what my be causing such a warning?
>

Yes, you've emitted an instruction that valgrind does not handle.
Searching for the same instruction string on google, I found that
there was already a bug filed for this.

You can try limiting your instruction set when you compile.  I do not
know exactly what instruction this is, but if you can determine that,
you can try to get the compiler not to emit it.

I notice that you're also running valgrind that only has copyright up
to 2012.  Maybe try the latest version?

  Brian

------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] Valgrind @ FOSDEM talk slides

[Mark W. <mj...@re...>]

Hi all,

Thanks for all you who came to Valgrind devroom at FOSDEM. I think the
interest in the talks surprised us all. We had to turn away some people
at some talks because the room was just full.

For those who missed it most slides are attached to the talk pages
listed at: https://fosdem.org/2014/schedule/track/valgrind/ (only the
SimuVEX one is still missing).

We also did try to record videos of the talks, but that wasn't a great
success. We were missing a firewire cable at the start, so couldn't
record anything. Then when we did get that cable the audio was really
bad/silent. Sorry about that. The FOSDEM video staff is trying to rescue
what is possible. If they are able to, the videos will turn up at:
http://video.fosdem.org/2014/ (we were in K4201 on Sunday - which
currently doesn't have any videos yet).

Lesson learned for next time:

- If we are doing video recordings we really need to find someone that
  is dedicated to doing that instead of having someone do it on the
  side. The FOSDEM staff offered a little training beforehand, but
  nobody had time to attend that training.

- We had a relaxed schedule with some extra "free" time so people
  could get some lunch and drinks in between. But that did mean some
  talks had not enough time allocated for them (25 minutes really isn't
  that much). And we did run out of time during the last BoF session. We
  should allocate a bit more time per talk if possible (or at least warn
  that 25 minutes is too short for both a talk and a demo), and instead
  of a BoF with lots of small issues we should push for some lightning
  talks (mini BoFs) in between the larger talks. Maybe combined with a
  BoF at the end to use some more time for lightning subjects that could
  use some more discussion.

- We really should organize some social get together before/after the
  technical talks. Just pick a pub for drinks or a restaurant for dinner
  to meet up.

Thanks,

Mark

Re: [Valgrind-users] Intel i3 vs.Intel I7 - unhandled instruction bytes: 0xC4 0xC2 0x79 0xF7 0xC9 0x89 0x45 0x80

[Brian B. <bri...@gm...>]

On Fri, Feb 7, 2014 at 3:28 PM, Adam.Jirasek <ada...@gm...> wrote:
> Hello
>
> I have a C program which I routinely test with valgrind.
> The platform is Intel i3 dual core, gcc-4.7.3. and for all my tests
> valgrind did not give any warning when I started my program
>
>
> Now I updated to a new computer
> Intel i7 4th generation, gcc-4.7.3 and when I start valgrind with my
> code I get:
>
> valgrind --tool=memcheck  --trace-children=yes
> --vex-iropt-register-updates=allregs-at-mem-access --leak-check=full
> --leak-resolution=high --show-reachable=yes  --track-origins=yes
> ../../Source/Server_Main.out --port 31000 --input_file
> Definition_File_PDT_Modes  --show
> ==28771== Memcheck, a memory error detector
> ==28771== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
> ==28771== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
> ==28771== Command: ../../Source/Server_Main.out --port 31000
> --input_file Definition_File_PDT_Modes --show
> ==28771==
> vex amd64->IR: unhandled instruction bytes: 0xC4 0xC2 0x79 0xF7 0xC9
> 0x89 0x45 0x80
> vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=1
> vex amd64->IR:   VEX=1 VEX.L=0 VEX.nVVVV=0x0 ESC=0F38
> vex amd64->IR:   PFX.66=1 PFX.F2=0 PFX.F3=0
> ==28771== valgrind: Unrecognised instruction at address 0x400da4b.
> ==28771==    at 0x400DA4B: _dl_important_hwcaps (in /lib64/ld-2.17.so)
> ==28771==    by 0x4007D8E: _dl_init_paths (in /lib64/ld-2.17.so)
> ==28771==    by 0x4003128: dl_main (in /lib64/ld-2.17.so)
> ==28771==    by 0x40152E7: _dl_sysdep_start (in /lib64/ld-2.17.so)
> ==28771==    by 0x4004EA4: _dl_start (in /lib64/ld-2.17.so)
> ==28771==    by 0x4001647: ??? (in /lib64/ld-2.17.so)
> ==28771==    by 0x5: ???
> ==28771==    by 0x7FF000056: ???
> ==28771==    by 0x7FF000073: ???
> ==28771==    by 0x7FF00007A: ???
> ==28771==    by 0x7FF000080: ???
> ==28771==    by 0x7FF00008D: ???
> ==28771== Your program just tried to execute an instruction that Valgrind
> ==28771== did not recognise.  There are two possible reasons for this.
> ==28771== 1. Your program has a bug and erroneously jumped to a non-code
> ==28771==    location.  If you are running Memcheck and you just saw a
> ==28771==    warning about a bad jump, it's probably your program's fault.
> ==28771== 2. The instruction is legitimate but Valgrind doesn't handle it,
> ==28771==    i.e. it's Valgrind's fault.  If you think this is the case or
> ==28771==    you are not sure, please let us know and we'll try to fix it.
> ==28771== Either way, Valgrind will now raise a SIGILL signal which will
> ==28771== probably kill your program.
> ==28771==
> ==28771== Process terminating with default action of signal 4 (SIGILL)
> ==28771==  Illegal opcode at address 0x400DA4B
> ==28771==    at 0x400DA4B: _dl_important_hwcaps (in /lib64/ld-2.17.so)
> ==28771==    by 0x4007D8E: _dl_init_paths (in /lib64/ld-2.17.so)
> ==28771==    by 0x4003128: dl_main (in /lib64/ld-2.17.so)
> ==28771==    by 0x40152E7: _dl_sysdep_start (in /lib64/ld-2.17.so)
> ==28771==    by 0x4004EA4: _dl_start (in /lib64/ld-2.17.so)
> ==28771==    by 0x4001647: ??? (in /lib64/ld-2.17.so)
> ==28771==    by 0x5: ???
> ==28771==    by 0x7FF000056: ???
> ==28771==    by 0x7FF000073: ???
> ==28771==    by 0x7FF00007A: ???
> ==28771==    by 0x7FF000080: ???
> ==28771==    by 0x7FF00008D: ???
> ==28771==
> ==28771== HEAP SUMMARY:
> ==28771==     in use at exit: 0 bytes in 0 blocks
> ==28771==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
> ==28771==
> ==28771== All heap blocks were freed -- no leaks are possible
> ==28771==
> ==28771== For counts of detected and suppressed errors, rerun with: -v
> ==28771== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
> Illegal instruction
>
>
>
> Any advice what my be causing such a warning?
>

Yes, you've emitted an instruction that valgrind does not handle.
Searching for the same instruction string on google, I found that
there was already a bug filed for this.

You can try limiting your instruction set when you compile.  I do not
know exactly what instruction this is, but if you can determine that,
you can try to get the compiler not to emit it.

I notice that you're also running valgrind that only has copyright up
to 2012.  Maybe try the latest version?

  Brian

Re: [Valgrind-users] Intel i3 vs.Intel I7 - unhandled instruction bytes: 0xC4 0xC2 0x79 0xF7 0xC9 0x89 0x45 0x80

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

On 07/02/14 23:28, Adam.Jirasek wrote:

> vex amd64->IR: unhandled instruction bytes: 0xC4 0xC2 0x79 0xF7 0xC9
> 0x89 0x45 0x80
> vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=1
> vex amd64->IR:   VEX=1 VEX.L=0 VEX.nVVVV=0x0 ESC=0F38
> vex amd64->IR:   PFX.66=1 PFX.F2=0 PFX.F3=0

So you're trying to execute an instruction that we don't support.

Actually though, that is an AVX encoded SHLX instruction, which we do 
support in the current release, so you just need to upgrade.

Alternatively, just don't compile with -march=native but rather choose 
some older processor to target.

> Any advice what my be causing such a warning?

It's not a warning, it's a hard error ;-)

Tom

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

[Valgrind-users] Intel i3 vs.Intel I7 - unhandled instruction bytes: 0xC4 0xC2 0x79 0xF7 0xC9 0x89 0x45 0x80

[Adam.Jirasek <ada...@gm...>]

Hello

I have a C program which I routinely test with valgrind.
The platform is Intel i3 dual core, gcc-4.7.3. and for all my tests
valgrind did not give any warning when I started my program


Now I updated to a new computer
Intel i7 4th generation, gcc-4.7.3 and when I start valgrind with my
code I get:

valgrind --tool=memcheck  --trace-children=yes
--vex-iropt-register-updates=allregs-at-mem-access --leak-check=full
--leak-resolution=high --show-reachable=yes  --track-origins=yes
../../Source/Server_Main.out --port 31000 --input_file
Definition_File_PDT_Modes  --show
==28771== Memcheck, a memory error detector
==28771== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==28771== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==28771== Command: ../../Source/Server_Main.out --port 31000
--input_file Definition_File_PDT_Modes --show
==28771==
vex amd64->IR: unhandled instruction bytes: 0xC4 0xC2 0x79 0xF7 0xC9
0x89 0x45 0x80
vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=1
vex amd64->IR:   VEX=1 VEX.L=0 VEX.nVVVV=0x0 ESC=0F38
vex amd64->IR:   PFX.66=1 PFX.F2=0 PFX.F3=0
==28771== valgrind: Unrecognised instruction at address 0x400da4b.
==28771==    at 0x400DA4B: _dl_important_hwcaps (in /lib64/ld-2.17.so)
==28771==    by 0x4007D8E: _dl_init_paths (in /lib64/ld-2.17.so)
==28771==    by 0x4003128: dl_main (in /lib64/ld-2.17.so)
==28771==    by 0x40152E7: _dl_sysdep_start (in /lib64/ld-2.17.so)
==28771==    by 0x4004EA4: _dl_start (in /lib64/ld-2.17.so)
==28771==    by 0x4001647: ??? (in /lib64/ld-2.17.so)
==28771==    by 0x5: ???
==28771==    by 0x7FF000056: ???
==28771==    by 0x7FF000073: ???
==28771==    by 0x7FF00007A: ???
==28771==    by 0x7FF000080: ???
==28771==    by 0x7FF00008D: ???
==28771== Your program just tried to execute an instruction that Valgrind
==28771== did not recognise.  There are two possible reasons for this.
==28771== 1. Your program has a bug and erroneously jumped to a non-code
==28771==    location.  If you are running Memcheck and you just saw a
==28771==    warning about a bad jump, it's probably your program's fault.
==28771== 2. The instruction is legitimate but Valgrind doesn't handle it,
==28771==    i.e. it's Valgrind's fault.  If you think this is the case or
==28771==    you are not sure, please let us know and we'll try to fix it.
==28771== Either way, Valgrind will now raise a SIGILL signal which will
==28771== probably kill your program.
==28771==
==28771== Process terminating with default action of signal 4 (SIGILL)
==28771==  Illegal opcode at address 0x400DA4B
==28771==    at 0x400DA4B: _dl_important_hwcaps (in /lib64/ld-2.17.so)
==28771==    by 0x4007D8E: _dl_init_paths (in /lib64/ld-2.17.so)
==28771==    by 0x4003128: dl_main (in /lib64/ld-2.17.so)
==28771==    by 0x40152E7: _dl_sysdep_start (in /lib64/ld-2.17.so)
==28771==    by 0x4004EA4: _dl_start (in /lib64/ld-2.17.so)
==28771==    by 0x4001647: ??? (in /lib64/ld-2.17.so)
==28771==    by 0x5: ???
==28771==    by 0x7FF000056: ???
==28771==    by 0x7FF000073: ???
==28771==    by 0x7FF00007A: ???
==28771==    by 0x7FF000080: ???
==28771==    by 0x7FF00008D: ???
==28771==
==28771== HEAP SUMMARY:
==28771==     in use at exit: 0 bytes in 0 blocks
==28771==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==28771==
==28771== All heap blocks were freed -- no leaks are possible
==28771==
==28771== For counts of detected and suppressed errors, rerun with: -v
==28771== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Illegal instruction



Any advice what my be causing such a warning?

Thanks

-- 
Adam Jirasek
Email: ada...@gm...

Re: [Valgrind-users] Frame-level wildcard not matching in suppression rule?

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

On Wed, 2014-02-05 at 18:17 -0500, Jeffrey Walton wrote:
> On Wed, Feb 5, 2014 at 6:06 PM, Tom Hughes <to...@co...> wrote:
> > On 05/02/14 23:00, Jeffrey Walton wrote:
> >
> >> Well, I'm not sure how to proceed since RAND_init_fips is the linchpin.
> >>
> >> A call to ... -> RAND_init_fips -> ... -> fips_aes_encrypt is OK.
> >>
> >> A call to ... -> AES_encrypt -> ... -> fips_aes_encrypt is BAD.
> >>
> >> I'm fairly certain I need to include RAND_init_fips to rule out a
> >> legitimate uninitialized read, but I'm not sure how to do it.
> >>
> >> Any ideas how to craft this rule?
> >
> >
> > You can't. There is no way to write a suppression which says "don't worry
> > about reads from the memory that was allocated at location X" which is what
> > you are tryng to do.
> Thanks Tom. That's not the answer I wanted :)
> 
> Jeff
Note that I believe we already had multiple requests to have
suppression entries which could match the "two" stacktraces of a
reported error, e.g. for the case you present,
but also for the helgrind errors, which also typically have
more two stacktraces.

So, you might enter an entry in bugzilla (with severy wish :)
and hope someone is interested to work on that.

Philippe