|
From: Eliot M. <mo...@cs...> - 2012-02-04 04:08:36
|
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 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 the latest stable release, and I didn't mess with that decoding. I will see if I can replicate it on svn head without my mods, but wanted to give a heads up. Any notion what's happening? It is becoming apparent that it might be nice to have more control over which x86 family processor is supported as the guest. If I downgraded the guest some then I think that HotSpot would avoid these instruction that I am having to add ... which come about apparently because valgrind claims via cpuid to support a really advanced processor, but then does not support all of its instructions. But I can see that it would be a significant project to support a range of guest processor capabilities controlled with flags, etc. Regards -- Eliot Moss |
|
From: Julian S. <js...@ac...> - 2012-02-04 12:02:35
|
> 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 the latest > stable release, and I didn't mess with that decoding. There was a massive overhaul lately of the x86_64 instruction decoding (a new framework) and insns were only added back into the new framework when test cases appeared (iow, on demand). A few didn't make it back in yet due to no test case, and CLFLUSH at least is amongst them. The old versions are #if 0'd out at the bottom of guest_amd64_toIR.c. I'd appreciate if you can find the right place for the ones you have fallen over and send a patch accordingly. You'll need to figure out which of dis_ESC_NONE, _ESC_0F, _ESC_0F38, _ESC_0F3A you need to put it/them in, based on which what escape bytes (0F, 0F38, 0F3A, or none) precede the main opcode. J |
|
From: Eliot M. <mo...@cs...> - 2012-02-04 16:29:24
|
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 slightly >> confused). Either way, it worked in the latest >> stable release, and I didn't mess with that decoding. > > There was a massive overhaul lately of the x86_64 instruction > decoding (a new framework) and insns were only added back into the > new framework when test cases appeared (iow, on demand). A few > didn't make it back in yet due to no test case, and CLFLUSH at > least is amongst them. The old versions are #if 0'd out at the > bottom of guest_amd64_toIR.c. > > I'd appreciate if you can find the right place for the ones you > have fallen over and send a patch accordingly. You'll need to figure > out which of dis_ESC_NONE, _ESC_0F, _ESC_0F38, _ESC_0F3A you need > to put it/them in, based on which what escape bytes (0F, 0F38, 0F3A, or > none) precede the main opcode. Thanks, and I clarified that it is indeed clflush. I am now straight about mod/rm encoding :-) . I have added clflush back, in dis_0F__SSE2. Since clflush uses the DisResult, I had the modify dis_0F__SSE2 to receive the DisResult* as an argument, and modify its caller to pass it. I am running tests now. This would be a good time to ask about how to prepare and send patches, i.e., what you want for these (re)additions. Regards -- Eliot |
|
From: Julian S. <js...@ac...> - 2012-02-07 10:31:05
|
> 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 discussed on mailing lists tend to get forgotten or otherwise fall through the cracks. A much more reliable approach, if you have bugs/patches in future, is to file a bug as described at http://valgrind.org/support/bug_reports.html and do all the discussion, patches, patch reviewing etc in the bug report. J |
|
From: Eliot M. <mo...@cs...> - 2012-02-07 20:43:20
|
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-level directory? > # remake, re-test > > # generate diff > cd VEX > svn diff -rHEAD > > # send the diff That's clear enough, but are you saying you want the tests as a separate patch? > One thing though. Bugs discussed on mailing lists tend to get > forgotten or otherwise fall through the cracks. A much more reliable > approach, if you have bugs/patches in future, is to file a bug as > described at http://valgrind.org/support/bug_reports.html > and do all the discussion, patches, patch reviewing etc in the bug > report. Right. I'll put in a bug report before submitting the patch. I hope to get to all this within a week (a big thing happening at work is draining any "spare" cycles). 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 under test, which is the DaCapo eclipse benchmark, complains that it can't create the workspace it's going to work on, throws an exception, and quits. There is no valgrind complaint. However, if I run the benchmark without valgrind, it completes normally. 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. My next step is to compare trace output without valgrind to valgrind --trace-syscalls=yes and see where the system calls majorly diverge. Of course it could be something else, but ... I also have one run that just core dumps. No valgrind end-of-run stuff, no complaint, just a core dump. I am scratching my head a bit on how to dig in on that one, since it seems to have jumped to address 0 and I don't get stack back trace ... but maybe I am being simple-minded about how I use gdb on this ... Is there a way to file a bug report with a core dump? Regards -- Eliot |
|
From: Julian S. <js...@ac...> - 2012-02-08 08:07:58
|
> 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 > end-of-run stuff, no complaint, just a core dump. You sure V was running the process at the time (as opposed to it running natively) ? At least with --stats=yes there is always some kind of post-run output. > Is there a way to file a bug report with a core dump? Not afaik. In general it wouldn't be much use unless you attached the depended-on libraries too. J |
|
From: Julian S. <js...@ac...> - 2012-02-07 22:20:06
|
> 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 implementation patch and the test patch. Be sure to svn add any new files (eg, test sources, expected outputs, etc) before doing svn diff, else they won't appear in the diffs. > That's clear enough, but are you saying you want the > tests as a separate patch? Well; it was an oversight, but, yes. > 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 under test, which is the DaCapo eclipse > benchmark, complains that it can't create the workspace > it's going to work on, throws an exception, and quits. > There is no valgrind complaint. However, if I run the > benchmark without valgrind, it completes normally. > > 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. > > My next step is to compare trace output without valgrind > to valgrind --trace-syscalls=yes and see where the system > calls majorly diverge. Of course it could be something > else, but ... > > I also have one run that just core dumps. No valgrind > end-of-run stuff, no complaint, just a core dump. I > am scratching my head a bit on how to dig in on that > one, since it seems to have jumped to address 0 and > I don't get stack back trace ... but maybe I am > being simple-minded about how I use gdb on this ... You're running with --smc-check=all or (better, if it works) --smc-check=all-non-file, right? These are mandatory when doing jitted code. Omitting it will cause the program under test to run off the road and disappear into the shrubbery. J |
|
From: Eliot M. <mo...@cs...> - 2012-02-07 22:33:57
|
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 under test, which is the DaCapo eclipse >> benchmark, complains that it can't create the workspace >> it's going to work on, throws an exception, and quits. >> There is no valgrind complaint. However, if I run the >> benchmark without valgrind, it completes normally. >> >> 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. >> >> My next step is to compare trace output without valgrind >> to valgrind --trace-syscalls=yes and see where the system >> calls majorly diverge. Of course it could be something >> else, but ... >> >> I also have one run that just core dumps. No valgrind >> end-of-run stuff, no complaint, just a core dump. I >> am scratching my head a bit on how to dig in on that >> one, since it seems to have jumped to address 0 and >> I don't get stack back trace ... but maybe I am >> being simple-minded about how I use gdb on this ... > > You're running with --smc-check=all or (better, if it works) > --smc-check=all-non-file, right? These are mandatory when > doing jitted code. Omitting it will cause the program > under test to run off the road and disappear into the shrubbery. The former, not the latter -- perhaps slower but safer, no? Someone who had used valgrind with a jitting JVM before clued me in on that one :-) ... Regards -- EM |