*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.
-----------------------------------------------------------------------------------
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Reply via email to