Menu
▾
▴
valgrind-users
|
From: Subhashish P. <sp...@gm...> - 2014-03-24 07:09:29
|
Hello! I posted this on valgrind-devel mailing list but got no reply so i'm posting it here. I have some new questions that I'd like to understand about unimplemented system calls. 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) What is this "ioctl 0x5309 with no size/redirection hints" and how could that be solved by PRE or POST functions? 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> How can we use that opcode to write wrappers? Regards, Subhashish Pradhan |
|
From: Tom H. <to...@co...> - 2014-03-24 08:41:10
|
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 (to...@co...) http://compton.nu/ |
|
From: Subhashish P. <sp...@gm...> - 2014-03-24 09:37:46
|
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 <to...@co...> 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 (to...@co...) > http://compton.nu/ |
|
From: Tom H. <to...@co...> - 2014-03-24 09:46:07
|
On 24/03/14 09:37, Subhashish Pradhan wrote: > 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? It means reading the kernel source to see what that ioctl does and what memory it accesses. > 2 - These ARG1, ARG2 and ARG3 in that source - what's their relation > to the syscall that's being wrapped? They are the system call arguments. > 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? Well PRINT prints a message and the others tell valgrind what registers and/or memory the system call is going to read/write so that it can check that things that will be read are initialised, and mark things which are written as initialised. > 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? Porting valgrind to a new platform is a major undertaking so you really need to start by reading the code carefully and understanding it all works. If you try and understand it by asking questions about every little detail here it will be very painful... > 5 - What's the speciality about the syscall-platform.S - why's it so > "magical" as referred in syswrap-main.c? Because it has to understand exactly how a system call happens on the platform, how to setup the arguments and make the call and collect the result, all the while making any registers which may be trampled on are saved, that the signal state is manipulated correctly and so on. All that should have been pretty obvious from reading one of them though, which is exactly what I just had to do to answer your question, as they have lots of comments in explaining what is going on. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Subhashish P. <sp...@gm...> - 2014-03-24 09:54:53
|
On Mon, Mar 24, 2014 at 3:15 PM, Tom Hughes <to...@co...> wrote: > On 24/03/14 09:37, Subhashish Pradhan wrote: > >> 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? > > > It means reading the kernel source to see what that ioctl does and what > memory it accesses. ... > Porting valgrind to a new platform is a major undertaking so you really need > to start by reading the code carefully and understanding it all works. If > you try and understand it by asking questions about every little detail here > it will be very painful... > ... > All that should have been pretty obvious from reading one of them though, > which is exactly what I just had to do to answer your question, as they have > lots of comments in explaining what is going on. > > > Tom > > -- > Tom Hughes (to...@co...) > http://compton.nu/ I think I'd have to really go through the source and work them out rather than getting the gist from documentation and stopping there. But may I come back here to ask about the correctness of an implementation or patch in future if I'm able to do that? Regards, Subhashish Pradhan |
Thanks for helping keep SourceForge clean.
X