|
From: Subhashish P. <sp...@gm...> - 2014-01-24 11:38:53
|
Hello, If Valgrind were to be ported to a new os, what modifications need be done to get it working? My assumptions till now have been: Implementing wrappers in coregrind/m_syswrap/syswrap-os.c Building the dependencies on host Compiling on that os. Am I wrong or missing anything? Thanks in advance. Regards, Subhashish |
|
From: Philippe W. <phi...@sk...> - 2014-01-24 20:44:04
|
On Fri, 2014-01-24 at 17:08 +0530, Subhashish Pradhan wrote: > Hello, > > > If Valgrind were to be ported to a new os, what modifications need be > done to get it working? > > > My assumptions till now have been: > > > Implementing wrappers in coregrind/m_syswrap/syswrap-os.c > Building the dependencies on host > Compiling on that os. Depends what the "new os" is. If that os looks a lot like linux it will be easier. If the os is completely different, it will be a lot more difficult. At fosdem, there will be a presentation about porting valgrind on solaris. That might give some clues for a "somewhat" easy port. You could also look at the diff-s for the bsd port. Otherwise, there is a tentative valgrind port to ms-windows, which will be the example of a wildly different os : sourceforge.net/projects/valgrind4win/ What is your target os ? Philippe |
|
From: Subhashish P. <sp...@gm...> - 2014-01-25 04:07:36
|
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? 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 ? Thanks again! Regards, Subhashish On Sat, Jan 25, 2014 at 2:13 AM, Philippe Waroquiers < phi...@sk...> wrote: > On Fri, 2014-01-24 at 17:08 +0530, Subhashish Pradhan wrote: > > Hello, > > > > > > If Valgrind were to be ported to a new os, what modifications need be > > done to get it working? > > > > > > My assumptions till now have been: > > > > > > Implementing wrappers in coregrind/m_syswrap/syswrap-os.c > > Building the dependencies on host > > Compiling on that os. > Depends what the "new os" is. > > If that os looks a lot like linux it will be easier. > If the os is completely different, it will be a lot more difficult. > > At fosdem, there will be a presentation about porting valgrind on > solaris. That might give some clues for a "somewhat" easy > port. You could also look at the diff-s for the bsd port. > > Otherwise, there is a tentative valgrind port to ms-windows, > which will be the example of a wildly different os : > sourceforge.net/projects/valgrind4win/ > > > What is your target os ? > > Philippe > > > > |
|
From: Philippe W. <phi...@sk...> - 2014-01-25 11:53:21
|
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 |
|
From: Subhashish P. <sp...@gm...> - 2014-01-25 13:34:57
|
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 > > > > |
|
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 >> >> >> > |