> Does valgrind restrict the number of open files? I noticed
> that the benchmark had over 50 files open, and might have
> hit a limit if it is set at 64 or something.
No; or if it does, to something quite high, like 1024 or some such.
> I also have one run that just core dumps. No valgrind
> en
On 2/7/2012 5:13 PM, Julian Seward wrote:
I'm clear about the 2 repos business now :-) ...
>> I'll post the other missing instruction as a bug report
>> too. I am also on the trail of something that looks like
>> an unimplemented (or differently implemented?) system call.
>> The Java program und
> Why only VEX? I also added tests in none/test/amd64.
> Is there some reason to avoid svn up in the valgrind
> top-level directory?
Oh, I forgot :)
So .. VEX and valgrind are different svn repos. You need to
svn up in both. Then svn diff -rHEAD in both. That generates
two patches -- the impl
On 2/7/2012 5:19 AM, Julian Seward wrote:
Thank you, Julian, for your patient instructions :-) ...
> # merge any other changes that happened in the meantime
> cd VEX
> svn up
> cd ..
Why only VEX? I also added tests in none/test/amd64.
Is there some reason to avoid svn up in the valgrind
top-lev
> This would be a good time to ask about how to prepare and send
> patches, i.e., what you want for these (re)additions.
# merge any other changes that happened in the meantime
cd VEX
svn up
cd ..
# remake, re-test
# generate diff
cd VEX
svn diff -rHEAD
# send the diff
One thing though. Bugs
On 2/4/2012 7:02 AM, Julian Seward wrote:
>
>> I did that, but when I run the updated valgrind on
>> the same program as before (Oracle's HotSpot JVM),
>> it fails on a 0xF 0xAE 0x3F instruction, which
>> appears to be either a CLFLUSH or an SFENCE (both
>> decode the same way in the docs, so I am
> I did that, but when I run the updated valgrind on
> the same program as before (Oracle's HotSpot JVM),
> it fails on a 0xF 0xAE 0x3F instruction, which
> appears to be either a CLFLUSH or an SFENCE (both
> decode the same way in the docs, so I am slightly
> confused). Either way, it worked in
A little while ago I posted about the non-implementation
of the AMD 64 SSE 4.2 instructions PCMPxSTRx for 16-bit
characters (many 8-bit sub-operations were supported).
I got them working, and was (reasonably) directed to
move to svn head if I want to be able to send in a
patch.
I did that, but whe
