valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] [Valgrind-developers] AVX-512 support inquiry

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

On Wed, 2016-09-07 at 10:23 +0200, Julian Seward wrote:
> Yes, I have seen AVX-512 looming on the horizon for a while.  Yes, we
> should support it.  Dealing with AVX/AVX2 was a lot of work, and there is
> not much AVX-512 available hardware out there, which may explain the
> relative lack of activity so far.
> 
> I would be willing to make the infrastructural changes in VEX and Valgrind
> necessary to provide a framework in which we can incrementally add support
> for individual instructions.  That would be: addition of support for 512
> bit registers, changes in the front end instruction decoding framework, and
> changes in the back end (if any required, possibly none).
> 
> One problem is the lack of hardware.  As I understand it, some but not
> all Skylake CPUs support AVX-512.  Having said that, if you are really
> looking for a working implementation on Knights Landing then it would
> be necessary to test any implementation both on Skylake+AVX512 and
> Knights Landing.
> 
> A good description of the instruction set is also necessary.  Is that
> publically available?
> 
> Can you make available, reliable, administrative-hassle-free
> remote access to a box that supports AVX-512?
Assuming there is an access to an AVX512 box, I can take in charge
the updates needed for valgrind gdbserver.

Note that one admin hassle free way to provide such a box is
for intel to donate such a box to gcc compile farm (and maybe even
better, to host it).


Philippe

Re: [Valgrind-users] [Valgrind-developers] AVX-512 support inquiry

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

Yes, I have seen AVX-512 looming on the horizon for a while.  Yes, we
should support it.  Dealing with AVX/AVX2 was a lot of work, and there is
not much AVX-512 available hardware out there, which may explain the
relative lack of activity so far.

I would be willing to make the infrastructural changes in VEX and Valgrind
necessary to provide a framework in which we can incrementally add support
for individual instructions.  That would be: addition of support for 512
bit registers, changes in the front end instruction decoding framework, and
changes in the back end (if any required, possibly none).

One problem is the lack of hardware.  As I understand it, some but not
all Skylake CPUs support AVX-512.  Having said that, if you are really
looking for a working implementation on Knights Landing then it would
be necessary to test any implementation both on Skylake+AVX512 and
Knights Landing.

A good description of the instruction set is also necessary.  Is that
publically available?

Can you make available, reliable, administrative-hassle-free
remote access to a box that supports AVX-512?

J



> -----Original Message-----
> From: Petar Jovanovic [mailto:mip...@gm...] 
> Sent: Monday, September 05, 2016 11:48 AM
> To: Jeff Hammond <jef...@gm...>
> Cc: val...@li...; val...@li...; Mark Wielaard <mj...@re...>
> Subject: Re: [Valgrind-developers] [Valgrind-users] AVX-512 support inquiry
> 
> On Mon, Sep 5, 2016 at 6:31 PM, Jeff Hammond <jef...@gm...> wrote:
>>
>> It would be really valuable to a number of HPC programmers. Many DOE 
>> labs use it heavily. I wish I could help implement but I don't have 
>> the relevant skills.
>>
> 
> It may be worth to open a bug at kde and track future discussion there.

Re: [Valgrind-users] [Valgrind-developers] AVX-512 support inquiry

[Knapp, R. L <ras...@in...>]

Petar and others on the Valgrind lists,  I asked this question because of just what Jeff states that there are many HPC programmers and HPC laboratories which use Valgrind extensively.  I do not mind opening a KDE bug discussion, but after not finding anything on this topic after searching through the KDE archive and the mailing lists archives, I thought first to ask via the mailing lists if anyone is currently working on contributing AVX-512 support to Valgrind. Intel's Knights Landing processor has shipped with AVX-512: https://software.intel.com/en-us/articles/intel-xeon-phi-x200-family-processor-performance-monitoring-reference-manual.  From the KDE bug discussions for AVX2 (https://bugs.kde.org/show_bug.cgi?id=305728 ), I realize adding AVX-512 support is a large piece of development.

Thank you all for your inputs.  I will open up a KDE bug discussion on this topic.

Regards,

Rashawn Knapp,
Intel Corporation


-----Original Message-----
From: Petar Jovanovic [mailto:mip...@gm...] 
Sent: Monday, September 05, 2016 11:48 AM
To: Jeff Hammond <jef...@gm...>
Cc: val...@li...; val...@li...; Mark Wielaard <mj...@re...>
Subject: Re: [Valgrind-developers] [Valgrind-users] AVX-512 support inquiry

On Mon, Sep 5, 2016 at 6:31 PM, Jeff Hammond <jef...@gm...> wrote:
>
> It would be really valuable to a number of HPC programmers. Many DOE 
> labs use it heavily. I wish I could help implement but I don't have 
> the relevant skills.
>

It may be worth to open a bug at kde and track future discussion there.

Regards,
Petar

------------------------------------------------------------------------------
_______________________________________________
Valgrind-developers mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-developers

Re: [Valgrind-users] AVX-512 support inquiry

[Jeff H. <jef...@gm...>]

On Monday, September 5, 2016, Mark Wielaard <mj...@re...> wrote:

> On Fri, 2016-09-02 at 00:05 +0000, Knapp, Rashawn L wrote:
> > With many new platforms hitting the market which include  AVX-512
> > instruction extensions, and as a valgrind user, I want to inquire
> > about Valgrind’s development underway to support these instructions.
> > I will appreciate any information available regarding this.
>
> As far as I know nobody is currently working on AVX-512 instruction and
> the new larger register support in valgrind. I don't even see a bug
> report requesting it. If someone does have hardware that supports
> AVX-512 it would be great if they could work on support for it.


There is a good chance we can arrange remote access to hardware within
Intel. Otherwise I can ask one of the DOE labs that has test hardware if
they can help. (A lab that doesn't have onerous remote access
limitations...). If all else fails, we loan out development boxes for
certain purposes.


>
> But
> wikipedia claims there is not much hardware out there (yet?) that has
> support for it: https://en.wikipedia.org/wiki/AVX-512#CPUs_with_AVX-512
>
>
Intel Xeon Phi 72xx aka Knights Landing is the only generally available
product that supports it.

Numerous unofficial sources and slides on GCC AVX-512 support by
Intel describe another implementation.


> Given your email address you might also want to ask people at Intel if
> they think AVX-512 support for valgrind would be useful and whether they
> could help with implementing support for it.
>
>
It would be really valuable to a number of HPC programmers. Many DOE labs
use it heavily. I wish I could help implement but I don't have the relevant
skills.

Jeff, who also works for Intel


> Thanks,
>
> Mark
>
> ------------------------------------------------------------
> ------------------
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li... <javascript:;>
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>


-- 
Jeff Hammond
jef...@gm...
http://jeffhammond.github.io/

Re: [Valgrind-users] AVX-512 support inquiry

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

On Fri, 2016-09-02 at 00:05 +0000, Knapp, Rashawn L wrote:
> With many new platforms hitting the market which include  AVX-512
> instruction extensions, and as a valgrind user, I want to inquire
> about Valgrind’s development underway to support these instructions.
> I will appreciate any information available regarding this.

As far as I know nobody is currently working on AVX-512 instruction and
the new larger register support in valgrind. I don't even see a bug
report requesting it. If someone does have hardware that supports
AVX-512 it would be great if they could work on support for it. But
wikipedia claims there is not much hardware out there (yet?) that has
support for it: https://en.wikipedia.org/wiki/AVX-512#CPUs_with_AVX-512

Given your email address you might also want to ask people at Intel if
they think AVX-512 support for valgrind would be useful and whether they
could help with implementing support for it.

Thanks,

Mark

[Valgrind-users] AVX-512 support inquiry

[Knapp, R. L <ras...@in...>]

Hello,

With many new platforms hitting the market which include  AVX-512 instruction extensions, and as a valgrind user, I want to inquire about Valgrind's development underway to support these instructions.  I will appreciate any information available regarding this.

Regards,

Rashawn Knapp
Intel Corporation

Re: [Valgrind-users] memcheck question

[Mark R. <ma...@cs...>]

We chase down pointers to find user values.  Some of those pointers we
modify to point to shadow memory (we copy chunks of the stack for safe
keeping, for example) and I believe those Daikon allocated blocks are
considered Valgrind space not client space.

Mark

> -----Original Message-----
> From: Julian Seward [mailto:js...@ac...]
> Sent: Tuesday, August 30, 2016 1:59 PM
> To: Mark Roberts; 'Philippe Waroquiers'
> Cc: val...@li...
> Subject: Re: [Valgrind-users] memcheck question
> 
> 
> I don't think that is_valid_for_valgrind should really be required.  That
> delimits areas which Valgrind itself can use but the client isn't allowed
to
> access.
> 
> In what way is is_valid_for_client too strict?
> 
> J

Re: [Valgrind-users] memcheck question

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

I don't think that is_valid_for_valgrind should really be required.  That
delimits areas which Valgrind itself can use but the client isn't allowed
to access.

In what way is is_valid_for_client too strict?

J

Re: [Valgrind-users] memcheck question

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

On Tue, 2016-08-30 at 10:02 -0700, Mark Roberts wrote:
> Ok - I was wrong.  The problem is that is_valid_for_client is too strict.  And or'ing that with 

> is_valid_for_valgrind is too loose.  In the end, by trial and error, I came with a test that seems to work for Daikon.
> 
> First, I check the original is_mem_defined, if that fails, then we're done.
> If that passes, then check is_valid_for_client and is_valid_for_valgrind.
> If they are both zero then the address is bad, otherwise it's ok.
> 
> Based on our tests, it looks like is_mem_defined does what I want, except it lets through references to user code pages.  The two is_valid checks catch this case.
> 
> So it seems I've fixed my problem - but I wonder if this technique makes sense to you?

Difficult to say, as I do not know what your tool exactly does.

However, here are a few remarks:

It is not very clear why a 'is_valid_for_valgrind' would be appropriate
for a tool to decide to dereference a 'guest pointer'. A guest (client)
pointer should only point to guest memory. If it points to valgrind
memory, this cannot be a valid guest pointer, and should not be
dereferenced.


Another remark is related to the use of 'is_mem_defined' : this will be
False if the data is partially defined. I am wondering what is the
desired behaviour for your tool for partially defined variables.
For sure, valid C/C++ code can have partially defined bytes.

For memcheck leak search, pointers must be fully defined.
But that is very specific to leak search.

Finally, I still wonder how you can have memory which is defined
but that you cannot read without having a SEGV.
As discussed earlier, something very strange must have happened to
achieve such a state.

Hoping this helps

Philippe

Re: [Valgrind-users] memcheck question

[Mark R. <ma...@cs...>]

Ok - I was wrong.  The problem is that is_valid_for_client is too strict.  And or'ing that with is_valid_for_valgrind is too loose.  In the end, by trial and error, I came with a test that seems to work for Daikon.

First, I check the original is_mem_defined, if that fails, then we're done.
If that passes, then check is_valid_for_client and is_valid_for_valgrind.
If they are both zero then the address is bad, otherwise it's ok.

Based on our tests, it looks like is_mem_defined does what I want, except it lets through references to user code pages.  The two is_valid checks catch this case.

So it seems I've fixed my problem - but I wonder if this technique makes sense to you?

Thanks,
Mark


> -----Original Message-----
> From: Mark Roberts [mailto:ma...@cs...]
> Sent: Tuesday, August 30, 2016 7:29 AM
> To: 'Philippe Waroquiers'
> Cc: 'val...@li...'
> Subject: RE: [Valgrind-users] memcheck question
> 
> Thank you, that is a big help.  I do have a follow up question.  When a
> Valgrind client allocates memory that will be used as a shadow copy of the
> user's data, I would guess that is not included in is_valid_for_client.  As an
> experiment, I ORd together the results of is_valid_for_cleint and
> is_valid_for_valgrind and the results of running Daikon matched our previous
> results - modulo now detecting reads from user space marked executable.
> 
> Thanks,
> Mark
> 
> 
> > -----Original Message-----
> > From: Philippe Waroquiers [mailto:phi...@sk...]
> > Sent: Monday, August 29, 2016 1:52 PM
> > To: Mark Roberts
> > Cc: val...@li...
> > Subject: Re: [Valgrind-users] memcheck question
> >
> >
> > Checking the protection can be done with VG_(am_is_valid_for_client).
> > This check is implemented by the address space manager, that maintains
> > the address space segments and protections.
> >

Re: [Valgrind-users] memcheck question

[Mark R. <ma...@cs...>]

Thank you, that is a big help.  I do have a follow up question.  When a Valgrind client allocates memory that will be used as a shadow copy of the user's data, I would guess that is not included in is_valid_for_client.  As an experiment, I ORd together the results of is_valid_for_cleint and is_valid_for_valgrind and the results of running Daikon matched our previous results - modulo now detecting reads from user space marked executable.

Thanks,
Mark


> -----Original Message-----
> From: Philippe Waroquiers [mailto:phi...@sk...]
> Sent: Monday, August 29, 2016 1:52 PM
> To: Mark Roberts
> Cc: val...@li...
> Subject: Re: [Valgrind-users] memcheck question
> 
> 
> Checking the protection can be done with VG_(am_is_valid_for_client).
> This check is implemented by the address space manager, that maintains the
> address space segments and protections.
> 

Re: [Valgrind-users] Finding function calls with Callgrind

[Ivo R. <iv...@iv...>]

2016-08-30 14:41 GMT+02:00 John Reiser <jr...@bi...>:

> > is it possible to detect all calls of some specific function in the code
> with Callgrind?
> >
> > Let's say I have some project and I know, that there's function
> SparseSolver() used several times and I need to know where specifically
> (caller function/file + line number, so I'd be able to find calls in the
> source code).
> >
> > Is it possible to find this out with Callgrind? I know about CScope,
> which has this functionality (http://stackoverflow.com/
> questions/36178082/use-cscope-to-find-function-calls-not-definitions-c-c),
> but it's just for C and I need to look in C++ and Fortran too.
>
> Why not use
>
>         objdump --disassemble-all my_program.exe  |  grep SparseSolver
>
> then 'addr2line'?  That way you don't require constructing the input data
> that is required to exercise all the call paths, nor must you run the
> program
> 30 times slower than normal.  Of course, any method is unlikely to find
> all the calls that have been inlined by the compiler or specialized+merged
> using constant propagation and link-time optimization.
>

A modern alternative to csope is OpenGrok [1].
I.

[1] https://opengrok.github.io/OpenGrok/

Re: [Valgrind-users] Finding function calls with Callgrind

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

> is it possible to detect all calls of some specific function in the code with Callgrind?
>
> Let's say I have some project and I know, that there's function SparseSolver() used several times and I need to know where specifically (caller function/file + line number, so I'd be able to find calls in the source code).
>
> Is it possible to find this out with Callgrind? I know about CScope, which has this functionality (http://stackoverflow.com/questions/36178082/use-cscope-to-find-function-calls-not-definitions-c-c), but it's just for C and I need to look in C++ and Fortran too.

Why not use

	objdump --disassemble-all my_program.exe  |  grep SparseSolver

then 'addr2line'?  That way you don't require constructing the input data
that is required to exercise all the call paths, nor must you run the program
30 times slower than normal.  Of course, any method is unlikely to find
all the calls that have been inlined by the compiler or specialized+merged
using constant propagation and link-time optimization.
	

[Valgrind-users] Finding function calls with Callgrind

[Martin B. <Mar...@se...>]

To Whom it may concern,

is it possible to detect all calls of some specific function in the code 
with Callgrind?

Let's say I have some project and I know, that there's function SparseSolver
() used several times and I need to know where specifically (caller 
function/file + line number, so I'd be able to find calls in the source 
code). 

Is it possible to find this out with Callgrind? I know about CScope, which 
has this functionality (http://stackoverflow.com/questions/36178082/use-
cscope-to-find-function-calls-not-definitions-c-c), but it's just for C and 
I need to look in C++ and Fortran too.


Thank you very much for your response.

Best regards,
Martin Beseda

Re: [Valgrind-users] memcheck question

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

On Mon, 2016-08-29 at 07:28 -0700, Mark Roberts wrote:
> The C/C++ front end to our tool Daikon includes most of Valgrind’s
> memcheck code.  We monitor the execution of a user’s program and
> record the values seen for various program variables.  As we follow
> pointer variables, we need to make sure they point to valid memory
> before we attempt to read the contents.  We have seen very
> intermittent failures in the code, but I think I have finally got a
> repeatable one.  Now to my question.
> 
>  
> 
> We are using “is_mem_defined” (in mc_main.) to test for “is it safe to
> read this location?” and that does not appear to be quite right.  It
> looks as though an address in a code segment is defined, but not
> readable.  We get a SIGSEGV with a bad permissions message when we
> try.  Whether or not that is the correct analysis is not as important
> as the primary question:
> 
>  
> 
> What is the proper way to check to see if an address is readable?
> And, similarly, is writable?

Memcheck VA bits are only maintaining addressibility and, when
addressable the definedness.
The memcheck bits do not allow to make the distinction based
on protection (r and/or w and/or x).

Checking the protection can be done with VG_(am_is_valid_for_client).
This check is implemented by the address space manager, that
maintains the address space segments and protections.

However, in case very strange things/bugs are done by the application,
possibly, the address space manager state is desynchronised
from the real state.

You might be interested to read mc_leakcheck.c heuristic
and memory scan, that are protecting themselves against
dereferencing 'invalid pointers'.
You might also read the test memcheck/tests/leak-segv-jmp.c
which verifies the behaviour when such strange things happens.


Philippe

Re: [Valgrind-users] memcheck question

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

> We are using “is_mem_defined” (in mc_main.) to test for “is it safe to read this location?” and that does not appear to be quite right.  It looks as though an address in a code segment is defined, but not readable.  We get a SIGSEGV with a bad permissions message when we try.  Whether or not that is
> the correct analysis is not as important as the primary question:
>
>
>
> What is the proper way to check to see if an address is readable?  And, similarly, is writable?

The *only* way to get a definitive answer is to attempt a write() from that address
to a temporary file.  If and only if you get no error, then the address is readable.

You can read and decode /proc/self/maps, but even if a page has PROT_READ
you might still get SIGBUS, such as when the page maps a hardware device
which does not respond to the particular address.

[Valgrind-users] memcheck question

[Mark R. <ma...@cs...>]

The C/C++ front end to our tool Daikon includes most of Valgrind's memcheck
code.  We monitor the execution of a user's program and record the values
seen for various program variables.  As we follow pointer variables, we need
to make sure they point to valid memory before we attempt to read the
contents.  We have seen very intermittent failures in the code, but I think
I have finally got a repeatable one.  Now to my question.

 

We are using "is_mem_defined" (in mc_main.) to test for "is it safe to read
this location?" and that does not appear to be quite right.  It looks as
though an address in a code segment is defined, but not readable.  We get a
SIGSEGV with a bad permissions message when we try.  Whether or not that is
the correct analysis is not as important as the primary question:

 

What is the proper way to check to see if an address is readable?  And,
similarly, is writable?

 

Thank you,

Mark Roberts

 

Re: [Valgrind-users] Unrecognized instruction in libgcrypt PRNG

[Markus T. <mar...@st...>]

Heyho,

John Reiser wrote:
> Meanwhile, it should be possible to make progress by avoiding the 'rdrand'
> instruction.  Is there some application flag or environment variable which
> says "do not use the hardware random number generator?" After that, try
> rebuilding libgcrypt-1.7.3 without "-mrdrnd".

surprisingly disabling the drnd feature in my make.conf and rebuilding libgcrypt
did not solve the issue.

Mark Wielaard wrote:
> You can help by building and testing valgrind from svn! Seriously, if you are
> able to build and test valgrind svn on your programs and let us know if you
> find any issues/regressions that would be appreciated.

I'll try to build it manually then. I'll let you know if I find something.

--Markus

Re: [Valgrind-users] Unrecognized instruction in libgcrypt PRNG

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

On Wed, 2016-08-24 at 22:50 +0200, Markus Teich wrote:
> When can we expect a new release containing the fix? 3.11.0
> is nearly a year old now.

Hopefully in ~3 weeks. But Julian is the release master and he is away
this week. So when he returns he might give you a slightly different
estimate. You can help by building and testing valgrind from svn!

Seriously, if you are able to build and test valgrind svn on your
programs and let us know if you find any issues/regressions that would
be appreciated.

Thanks,

Mark

Re: [Valgrind-users] Unrecognized instruction in libgcrypt PRNG

[Markus T. <mar...@st...>]

Mark Wielaard wrote:
> This is https://bugs.kde.org/show_bug.cgi?id=353370 fixed in VEX svn r3197.

Heyho,

thanks for the hint. When can we expect a new release containing the fix? 3.11.0
is nearly a year old now.

--Markus

Re: [Valgrind-users] Unrecognized instruction in libgcrypt PRNG

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

On Wed, 2016-08-24 at 07:42 -0700, John Reiser wrote:
> Markus Teich wrote:
> 
> > vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0xC7 0xF0 0x72 0x4 0xFF 0xC9
> > vex amd64->IR:   REX=1 REX.W=1 REX.R=0 REX.X=0 REX.B=0
> > vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=0F
> > vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
> > ==10769== valgrind: Unrecognised instruction at address 0x60082d3.
> > ==10769==    at 0x60082D3: poll_drng.isra.0 (in /usr/lib64/libgcrypt.so.20.1.3)
> 
> > I have a x86_64 gentoo system with valgrind-3.11.0 and libgcrypt-1.7.3 installed.
> > The CFLAGS from my make.conf are:
> >
> > CFLAGS="-O2 -pipe"
> > CFLAGS="${CFLAGS} -march=core-avx2 -mtune=core-avx2 -mcx16 -msahf -mmovbe -maes"
> > CFLAGS="${CFLAGS} -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop"
> > CFLAGS="${CFLAGS} -mbmi -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt"
> > CFLAGS="${CFLAGS} -mrdrnd -mf16c -mfsgsbase --param l1-cache-size=32"
> > CFLAGS="${CFLAGS} --param l1-cache-line-size=64 --param l2-cache-size=4096"
> 
> gdb says that the bytes 0xF 0xC7 0xF0 are "rdrand %rax".  Evidently valgrind's libVEX
> does not know about this, or perhaps the preceding 0x48 prefix has confused valgrind.
> [gdb 7.9.1-20.fc22 didn't know how to interpret 0x48 0xF 0xC7 0xF0, either.]

This is https://bugs.kde.org/show_bug.cgi?id=353370 fixed in VEX svn
r3197.

Re: [Valgrind-users] Unrecognized instruction in libgcrypt PRNG

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

Markus Teich wrote:

> vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0xC7 0xF0 0x72 0x4 0xFF 0xC9
> vex amd64->IR:   REX=1 REX.W=1 REX.R=0 REX.X=0 REX.B=0
> vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=0F
> vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
> ==10769== valgrind: Unrecognised instruction at address 0x60082d3.
> ==10769==    at 0x60082D3: poll_drng.isra.0 (in /usr/lib64/libgcrypt.so.20.1.3)

> I have a x86_64 gentoo system with valgrind-3.11.0 and libgcrypt-1.7.3 installed.
> The CFLAGS from my make.conf are:
>
> CFLAGS="-O2 -pipe"
> CFLAGS="${CFLAGS} -march=core-avx2 -mtune=core-avx2 -mcx16 -msahf -mmovbe -maes"
> CFLAGS="${CFLAGS} -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop"
> CFLAGS="${CFLAGS} -mbmi -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt"
> CFLAGS="${CFLAGS} -mrdrnd -mf16c -mfsgsbase --param l1-cache-size=32"
> CFLAGS="${CFLAGS} --param l1-cache-line-size=64 --param l2-cache-size=4096"

gdb says that the bytes 0xF 0xC7 0xF0 are "rdrand %rax".  Evidently valgrind's libVEX
does not know about this, or perhaps the preceding 0x48 prefix has confused valgrind.
[gdb 7.9.1-20.fc22 didn't know how to interpret 0x48 0xF 0xC7 0xF0, either.]
So, please file a bug at http://valgrind.org/support/bug_reports.html .
Just copy+paste your original message into the bug report, and give a title
such as "rdrand not recognized on amd64".  Give the version of your compiler, too:
the output from "gcc --version" .

Meanwhile, it should be possible to make progress by avoiding the 'rdrand' instruction.
Is there some application flag or environment variable which says "do not use
the hardware random number generator?"
After that, try rebuilding libgcrypt-1.7.3 without "-mrdrnd".

-- 




	

[Valgrind-users] Unrecognized instruction in libgcrypt PRNG

[Markus T. <mar...@st...>]

Heyho,

when running valgrind on an application linking to libgcrypt, I get the
following error:

vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0xC7 0xF0 0x72 0x4 0xFF 0xC9
vex amd64->IR:   REX=1 REX.W=1 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=0F
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
==10769== valgrind: Unrecognised instruction at address 0x60082d3.
==10769==    at 0x60082D3: poll_drng.isra.0 (in /usr/lib64/libgcrypt.so.20.1.3)
==10769==    by 0x6008389: _gcry_rndhw_poll_fast (in /usr/lib64/libgcrypt.so.20.1.3)
==10769==    by 0x6004AF4: do_fast_random_poll (in /usr/lib64/libgcrypt.so.20.1.3)
==10769==    by 0x600546B: _gcry_rngcsprng_fast_poll (in /usr/lib64/libgcrypt.so.20.1.3)
==10769==    by 0x5F57912: _gcry_vcontrol (in /usr/lib64/libgcrypt.so.20.1.3)
==10769==    by 0x5F54390: gcry_control (in /usr/lib64/libgcrypt.so.20.1.3)
==10769==    by 0x507FBC6: GNUNET_CRYPTO_random_init (crypto_random.c:301)
==10769==    by 0x400F269: call_init.part.0 (in /lib64/ld-2.22.so)
==10769==    by 0x400F37A: _dl_init (in /lib64/ld-2.22.so)
==10769==    by 0x4000C79: ??? (in /lib64/ld-2.22.so)

I have a x86_64 gentoo system with valgrind-3.11.0 and libgcrypt-1.7.3 installed.
The CFLAGS from my make.conf are:

CFLAGS="-O2 -pipe"
CFLAGS="${CFLAGS} -march=core-avx2 -mtune=core-avx2 -mcx16 -msahf -mmovbe -maes"
CFLAGS="${CFLAGS} -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop"
CFLAGS="${CFLAGS} -mbmi -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt"
CFLAGS="${CFLAGS} -mrdrnd -mf16c -mfsgsbase --param l1-cache-size=32"
CFLAGS="${CFLAGS} --param l1-cache-line-size=64 --param l2-cache-size=4096"

Please keep me in the CC in your replies, since I am no list member.

--Markus

Re: [Valgrind-users] vdsqrt

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

On 19/08/16 18:32, dave winfield wrote:
> 3.8.1

That's ancient.  Try 3.11.0 or the trunk.

J

Re: [Valgrind-users] vdsqrt

[dave w. <wav...@gm...>]

3.8.1

Thanks!

On Fri, Aug 19, 2016 at 12:11 PM, Julian Seward <js...@ac...> wrote:

>
> > Appreciate any thoughts,
>
> What version of Valgrind is this?
>
> J
>
>
>