Hello again! Ok when I add case 0x5309: at line 5500 and build valgrind again and run the eject under it, it gives me this:
sprkv5@cb-4440s:~$ valgrind ./eject ==29522== Memcheck, a memory error detector ==29522== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==29522== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==29522== Command: ./eject ==29522== ==29522== ==29522== HEAP SUMMARY: ==29522== in use at exit: 0 bytes in 0 blocks ==29522== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==29522== ==29522== All heap blocks were freed -- no leaks are possible ==29522== ==29522== For counts of detected and suppressed errors, rerun with: -v ==29522== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2) But I have some more questions - 1 - It was mentioned "it may well be that no memory is read/written, but you'd have to look at the kernel and see what that ioctl does to be sure." Does it mean using strace or looking at kernel logs using dmesg? 2 - These ARG1, ARG2 and ARG3 in that source - what's their relation to the syscall that's being wrapped? 3 - The PRINT(), PRE_MEM_READ(), PRE_REG_READ(), POST_MEM_WRITE - where in the source is their definition? I need to understand what they do - I get the context that they are the read/write primitives of valgrind or am I wrong here? 4 - I would be porting valgrind to GNUMach based Hurd - so I'd have to handle RPCs there, so basically I'd need to implement syswrap-platform.c, and maybe syscall-platform.S, am I right? 5 - What's the speciality about the syscall-platform.S - why's it so "magical" as referred in syswrap-main.c? Regards, Subhashish Pradhan On Mon, Mar 24, 2014 at 2:10 PM, Tom Hughes <t...@compton.nu> wrote: > On 24/03/14 07:09, Subhashish Pradhan wrote: > >> The eject.c example provided here at http://leapster.org/linux/cdrom/ >> will compile successfuly >> with a #include <stdlib.h>. Then when run it under as "valgrind >> ./eject', it still reports: >> >> ==6212== Command: ./eject >> ==6212== >> ==6212== Warning: noted but unhandled ioctl 0x5309 with no size/direction >> hints >> ==6212== This could cause spurious value errors to appear. >> ==6212== See README_MISSING_SYSCALL_OR_IOCTL for guidance on >> writing a proper wrapper. >> >> Why would that be? (since ioctls are wrapped in >> coregrind/m_syswrap/syswrap-linux.c) > > > The ioctl system call in general is wrapped, but it doesn't know about every > single ioctl, so you may need to teach it. If you read the file it mentions > in the message you will find some hints, especially in the final section > about ioctls. > > >> What is this "ioctl 0x5309 with no size/redirection hints" and how >> could that be solved >> by PRE or POST functions? > > > Because the ioctl number can encode the size and direction of memory access > valgrind can sometimes guess at how much memory will be read or written by a > system call. > > Not all ioctls actually make use of that facility though, and even when they > do it may not be right, so valgrind has specific wrappers for many ioctls to > make sure we do the right thing. > > >> Or specifically, I couldn't understand the 0x5309 operation code >> context as explained in this post on this mailing list below: >> >> <http://valgrind.10908.n7.nabble.com/noted-but-unhandled-ioctl-0xae03-with-no-size-direction-hints-tp38957p38959.html> > > > Add it to the switch statement in the ioctl wrappers, with appropriate calls > to indicate how much memory is read/written. > > In this case, and assuming that ioctl triggers the eject, it may well be > that no memory is read/written, but you'd have to look at the kernel and see > what that ioctl does to be sure. > > Tom > > -- > Tom Hughes (t...@compton.nu) > http://compton.nu/ ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
