|
From: Subhashish P. <sp...@gm...> - 2014-03-21 19:19:50
|
Hello again! 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? On Sat, Jan 25, 2014 at 7:04 PM, Subhashish Pradhan <sp...@gm...> wrote: > Thanks! > > Regards, > Subhashish > > > On Sat, Jan 25, 2014 at 5:23 PM, Philippe Waroquiers > <phi...@sk...> wrote: >> >> On Sat, 2014-01-25 at 09:37 +0530, Subhashish Pradhan wrote: >> > Hello again, >> > >> > >> > My target os is GNU Hurd. >> > >> > >> > Basically I'd have to implement the system call wrappers in coregrind >> > or is there something else required? >> For sure, there will be a lot of other things (e.g. the configure >> machinery, the tests, assembly code, ...) but the source of information >> is the sources :). >> >> In the c code, basically, everywhere where you will find a bunch of >> #if defined .. >> #elif defined ... >> which are mentioning linux/darwin, you will very probably have >> to do something for VGO_hurd and/or VGP_x86_hurd and/or VGP_amd64_hurd >> (or any other cpu you want to support for hurd). >> >> >> > >> > >> > I would look into and compare with the Solaris port - seems nicely >> > documented. >> > >> > >> > Also, I would like to discuss about how they are implemented. There >> > are the PRE(sys_call) and POST(sys_call), the system call table (at >> > the end, that I seem to get) and some other functions. What are these >> > other functions that we see in the coregrind/m_syswrap/syswrap-os.c? >> > >> > So how does this composition of functions work as a prt of >> > syswrap-os.c ? >> Porting to a new os is a non trivial work, I guess you will have >> to first do a lot of initial reading/work/experimenting/... >> before specific problems/questions might be discussed. >> >> Sorry for not be able to help more >> >> Philippe >> >> >> > |