*On 01/31/2015 07:07 AM, Carl Ponder wrote:*
I ran into this output from valgrind
*==21898== Warning: noted but unhandled ioctl 0x30000001 with no
size/direction hints.*
==21898== This could cause spurious value errors to appear.
==21898== See README_MISSING_SYSCALL_OR_IOCTL for guidance on
writing a proper wrapper.
==21898== at 0x59C98C7: ioctl (in /lib64/libc-2.12.so)
==21898== by 0x61D148D: ??? (in /usr/lib64/libcuda.so.346.29)
==21898== by 0x62B7B94: ??? (in /usr/lib64/libcuda.so.346.29)
==21898== by 0x6271A6F: ??? (in /usr/lib64/libcuda.so.346.29)
==21898== by 0x61AE21C: cuInit (in /usr/lib64/libcuda.so.346.29)
==21898== by 0x414D89: __pgi_uacc_cuda_init (cuda_init.c:225)
==21898== by 0x408ACC: __pgi_uacc_enumerate (init.c:420)
==21898== by 0x408E64: __pgi_uacc_initialize (init.c:580)
==21898== by 0x405C09: __pgi_uacc_dataenterstart
(dataenterstart.c:45)
==21898== by 0x404A19: MAIN_ (test_synccheck.F:177)
==21898== by 0x4027F3: main (in /home-2/cponder/Temp.064/synccheck)
From following the instructions in
http://valgrind.org/docs/manual/dist.readme-missing.html
I added this entry to the filecoregrind/m_syswrap/syswrap-linux.c :
10166 PRE(0x30000001)
10167 {
10168 PRINT("NVIDIA UvmInitialize ioctl");
10169 }
It didn't affect the output, though, I still see the same messages and
it looks like the abovePRINT statement didn't get executed.
I saw this message in two places in thevalgrind build log:
m_syswrap/syswrap-linux.c:10166: warning: no previous prototype for
‘vgSysWrap_linux_0x30000001_before’
The instructions also say this regarding system-calls:
Also, add it to the syscall_table[] array; use one of GENX_, GENXY
LINX_, LINXY, PLAX_, PLAXY.
GEN* for generic syscalls (in syswrap-generic.c), LIN* for linux
specific ones (in syswrap-linux.c) and PLA* for the platform
dependant ones (in syswrap-$(PLATFORM)-linux.c).
The *XY variant if it requires a PRE() and POST() function, and
the *X_ variant if it only requires a PRE()
function.
There isn't anysyscall_table in the syswrap-linux.c file, also I'm not
sure if this applies to ioctl's anyway.
So the obvious questions are (a) whether I put thePRE(0x30000001) macro
in the right file, and if there are other edits that I have to make to
the valgrind sources as well.
This particular ioctl doesn't take any arguments and only returns an
integer status value.
For now I just want to remove the warning-message fromvalgrind, after
that I'll look more closely at changes it might possibly make to the
global data state.
Thanks,
Carl Ponder
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
