Re: [Valgrind-users] Handling ioctl 0x30000001 in valgrind?

[Carl P. <cp...@nv...>]

*On 05/18/2015 09:12 AM, Carl Ponder wrote:*
>
>     I tried inserting print-statements into this function in the
>     filecoregrind/m_syswrap/syswrap-linux.c
>
>         5406 PRE(sys_ioctl)
>         5407 {
>         5408    *flags |= SfMayBlock;
>         5409
>         5410    ARG2 = (UInt)ARG2;
>         5411
>         *5412 PRINT("ioctl ARG1=0x%lx\n", (unsigned long) ARG1 );**
>         **5413 PRINT("ioctl ARG2=0x%lx\n", (unsigned long) ARG2 );**
>         **5414 PRINT("ioctl ARG3=0x%lx\n", (unsigned long) ARG3 );*
>
>     but didn't see any output, it looks like this function doesn't get
>     called on ioctl0x30000001.
>
*On 05/18/2015 09:17 AM, Tom Hughes wrote:*
>
>     You know PRINT only prints when --trace-syscalls=yes is used?
>
Ok got it.... here is what worked, in the 
file*coregrind/m_syswrap/syswrap-linux.c*:

   5406 PRE(sys_ioctl)
   5407 {
   5408   *flags |= SfMayBlock;
   5409
   5410   ARG2 = (UInt)ARG2;
   5411
   5412   // We first handle the ones that don't use ARG3 (even as a
   5413   // scalar/non-pointer argument).
   5414   switch (ARG2 /* request */) {
                     .....
*  5467   /* NVIDIA UvmInitialize */
   5468   case 0x30000001:
   5469      PRINT("sys_ioctl ( %ld, 0x%lx, 0x%lx )",ARG1,ARG2,ARG3);
   5470      PRE_REG_READ3(long, "ioctl",
   5471                    unsigned int, fd, unsigned int, request, 
unsigned long, arg);
   5472      return;*
   5473
   5474   default:

So it shuts off the warning message

    *==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.

but doesn't do anything to manage the memory state.
The output I'm getting from--trace-syscalls=yes is

    SYSCALL[20867,1](16) *sys_ioctl ( 38, 0x30000001, 0x0 *) --> [async]
    ...
    SYSCALL[20867,1](16) ... [async] --> Success(0x0:0x0)

so it doesn't look like any memory-range is being passed in.
I'm checking with our engineers to see if there is any special 
processing that needs to happen here, and we'll also have to watch and 
see if any other NVIDIA-specific calls are happening.

One question to you: does it make sense to be hard-coding the 
*0x30000001* case into the generalioctl handler, or should there be an 
NVIDIA-specific file in the coregrind/m_syswrap directory?
Thanks,

                 Carl


-----------------------------------------------------------------------------------
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.
-----------------------------------------------------------------------------------