|
From: Adrian P. <ad...@gm...> - 2009-03-26 01:09:46
|
Hi, I am considering porting valgrind to Haiku ( http://www.haiku-os.org/ ). I am aware that it is unlikely that my efforts would be integrated into the main tree, but I am ok with keeping the patchset externally. Could you tell me what are the main challenges when porting valgrind to a new platform? I want to limit myself to coregrind and nulgrind. Am I correct, that there is little platform-dependent code in files which do not have a platform name in their filename? Could you give me a brief explanation of what each platform-dependent piece's functions are? Regards, Adrian. -- Czy ty orzeł, czy ty kawka? -wkrótce zdłabi kaszel, czkawka. Śmierć szyję zaszyje. |
|
From: Nicholas N. <n.n...@gm...> - 2009-03-26 02:57:09
|
2009/3/25 Adrian Panasiuk <ad...@gm...>: > Hi, > I am considering porting valgrind to Haiku ( http://www.haiku-os.org/ > ). I am aware that it is unlikely that my efforts would be integrated > into the main tree, but I am ok with keeping the patchset externally. > > Could you tell me what are the main challenges when porting valgrind > to a new platform? I want to limit myself to coregrind and nulgrind. > Am I correct, that there is little platform-dependent code in files > which do not have a platform name in their filename? Could you give me > a brief explanation of what each platform-dependent piece's functions > are? You'll need to port to a new arch/OS combination, eg. x86/Haiku. docs/internals/porting-HOWTO.txt has some details, but it's also out-of-date and so shouldn't be trusted completely. Limiting yourself to coregrind and nulgrind sounds strange -- is that really what you want? Then you'll be able to run programs more slowly than normal under Valgrind but not learn anything useful about them. Surely you want Memcheck as well? Platform-dependent code is sprinkled in lots of places, not just the files with names like foo-x86-linux.c. Look for things like "#if defined (VGO_linux)" and "#if defined(VGP_x86_linux)". A port is a lot of work. Porting Valgrind is much harder than porting a normal program. For example, Greg Parker spent about 4 years working on the Mac OS X port in his spare time before it got incorporated onto a branch. The patch that was incorporated was 31,000 lines of code. And you'll need a really good idea of how the Haiku kernel interfaces with user-space, and you'll have to learn a lot about Valgrind too. Nick |
|
From: Tor L. <tm...@ik...> - 2009-03-26 09:06:15
|
> For example, Greg Parker spent about 4 years > working on the Mac OS X port in his spare time before it got > incorporated onto a branch. Is this the DARWIN branch? Was this four year wait just because of modesty or secrecy on his side, or do the main developers in principle oppose allowing new ports even onto a branch until they are "finished" and actually work, or something? I am contemplating porting Valgrind to x86-windows and have done some experimentation, and it doesn't seem impossible at all. (I am not naïve, I do know it will be a lot of work, and I do know that many things in Windows are totally different from typical Unixes on x86. OTOH, it is just software, nothing is impossible;) And the lack of fork() and exec() even makes some things simpler than on Unix, I guess...) So I am just wondering, if I start doing this in earnest, will I forever have to just keep my stuff in a local tree (and offer as separate patched source tarballs, if ever it gets so far that others could sensibly help), or would it be allowed onto a branch, or as properly ifdeffed etc, even trunk? Btw, a question about the indentation and spacing style in Valgrind... it is somewhat different in different files. Obviously, for existing files one should use the style of the surrounding code, but which file is a "canonical" one to have a s a guide when writing completely new source files? --tml |
|
From: Nicholas N. <n.n...@gm...> - 2009-03-26 15:10:02
|
On Thu, Mar 26, 2009 at 4:05 AM, Tor Lillqvist <tm...@ik...> wrote: >> For example, Greg Parker spent about 4 years >> working on the Mac OS X port in his spare time before it got >> incorporated onto a branch. > > Is this the DARWIN branch? Yes. > Was this four year wait just because of modesty or secrecy on his > side, or do the main developers in principle oppose allowing new ports > even onto a branch until they are "finished" and actually work, or > something? Mostly modesty/secrecy/copyright-issues-with-Apple, AFAIK. > So I am just wondering, if I start doing this in earnest, will I > forever have to just keep my stuff in a local tree (and offer as > separate patched source tarballs, if ever it gets so far that others > could sensibly help), or would it be allowed onto a branch, or as > properly ifdeffed etc, even trunk? See http://www.valgrind.org/info/platforms.html ("porting plans" at the bottom). If you could get Windows working without completely gutting Valgrind that would be very useful because Windows is so widespread. As for branches, we don't have an official policy but having something that works at least on small programs would be much more convincing than something that doesn't. And the bar for putting something on a branch is much lower than including it in the trunk -- eg. the Darwin branch is pretty capable but still has some way to go before it will be merged to the trunk. The reason being that the trunk is the basis of releases and we wouldn't want a release to include a really flaky port -- that's the kind of thing people can get themselves from SVN and their expectations will be set appropriately. > Btw, a question about the indentation and spacing style in Valgrind... > it is somewhat different in different files. Obviously, for existing > files one should use the style of the surrounding code, but which file > is a "canonical" one to have a s a guide when writing completely new > source files? I think .c and .h files are pretty consistently 3-space indents and perl scripts are 4-space. Nick |
|
From: Greg P. <gp...@ap...> - 2009-03-27 02:11:05
|
On Mar 26, 2009, at 2:05 AM, Tor Lillqvist wrote: >> For example, Greg Parker spent about 4 years >> working on the Mac OS X port in his spare time before it got >> incorporated onto a branch. > > Is this the DARWIN branch? > > Was this four year wait just because of modesty or secrecy on his > side, or do the main developers in principle oppose allowing new ports > even onto a branch until they are "finished" and actually work, or > something? Copyright issues did delay the release. But note that after 30,000 lines of changes, it's still not a "finished" port. And Mac OS X is a relatively friendly porting environment for Valgrind - much of it is Unix so much of the Linux code can be reused. Porting to Windows or Haiku or some other OS that is fundamentally not-a-Unix would be a big step up in difficulty. (Also, kernel and C library source code is invaluable. That would be another obstacle on Windows in particular.) > So I am just wondering, if I start doing this in earnest, will I > forever have to just keep my stuff in a local tree (and offer as > separate patched source tarballs, if ever it gets so far that others > could sensibly help), or would it be allowed onto a branch, or as > properly ifdeffed etc, even trunk? Merging a Windows port to the existing repository would take time and effort. In particular, the portability infrastructure would need to be built up in some places where all current ports happen to be the same. The natural path is probably something like what the Darwin port followed. Start with an entirely separate tree that you can mangle at your leisure. Later move to patches then a branch then the trunk, as your changes settle down and you add any necessary multi-platform infrastructure. The Darwin port had two ground-up restarts in its first two years, as various experiments came and went. You really don't want to be anywhere near trunk when your change rate looks like that. -- Greg Parker gp...@ap... Runtime Wrangler |
|
From: Nicholas N. <n.n...@gm...> - 2009-03-27 12:46:32
|
On Thu, Mar 26, 2009 at 9:10 PM, Greg Parker <gp...@ap...> wrote: > > Merging a Windows port to the existing repository would take time and > effort. In particular, the portability infrastructure would need to be built > up in some places where all current ports happen to be the same. To give you an idea, I've been working on merging Greg's Darwin port for about 2 months now, with a couple of weeks of help from Julian, and I would estimate we are roughly half way towards merging it with the trunk. Nick |
|
From: Filipe C. <fi...@gm...> - 2009-03-26 10:45:52
|
F On Thu, Mar 26, 2009 at 09:05, Tor Lillqvist <tm...@ik...> wrote: > > For example, Greg Parker spent about 4 years > > working on the Mac OS X port in his spare time before it got > > incorporated onto a branch. > > Is this the DARWIN branch? > > Was this four year wait just because of modesty or secrecy on his > side, or do the main developers in principle oppose allowing new ports > even onto a branch until they are "finished" and actually work, or > something? The patch wasn't available until "recently", but I don't know if Greg spoke/emailed any of the developers off-list in the meantime... > I am contemplating porting Valgrind to x86-windows and have done some > experimentation, and it doesn't seem impossible at all. (I am not > naïve, I do know it will be a lot of work, and I do know that many > things in Windows are totally different from typical Unixes on x86. > OTOH, it is just software, nothing is impossible;) And the lack of > fork() and exec() even makes some things simpler than on Unix, I > guess...) That's strange. If you lack exec(), you won't be able to run valgrind in it's normal form (valgrind will search for a tool executable and exec() it). Btw, a question about the indentation and spacing style in Valgrind... > it is somewhat different in different files. Obviously, for existing > files one should use the style of the surrounding code, but which file > is a "canonical" one to have a s a guide when writing completely new > source files? > >From what I saw in VEX, the spacing was consistently 3 space characters to indent. In coregrind I think it was the same, but I don't know about other tools. Also, some parts of files can have the indentation broken due to someone using different settings. Regards, F |
|
From: Tor L. <tm...@ik...> - 2009-03-26 11:06:54
|
> That's strange. If you lack exec(), you won't be able to run valgrind in > it's normal form (valgrind will search for a tool executable and exec() it). Trust me, I know what I am doing. The way the valgrind launcher starts the tool is the least of the problems here. And that code is already in platform-dependent launcher-foo.c files anyway, so doing it differently on Windows than on Linux and AIX5 won't cause any ifdefs. --tml |
|
From: Nicholas N. <n.n...@gm...> - 2009-03-27 12:45:05
|
On Thu, Mar 26, 2009 at 9:10 PM, Greg Parker <gp...@ap...> wrote: > > Porting to Windows or Haiku or some other OS > that is fundamentally not-a-Unix would be a big step up in difficulty. > (Also, kernel and C library source code is invaluable. That would be another > obstacle on Windows in particular.) Another problem with Windows, AIUI, is that the syscall interface between the kernel and user-space isn't well defined (ie. not public and subject to change). Rather, what is well defined is the equivalent of libc. So writing syscall wrappers is problematic. A couple of years ago there was some more detailed discussion about a Windows port on the dev list. You might be able to find the thread with some searching. I couldn't find it, but I could find this: http://www.mail-archive.com/val...@li.../msg01402.html which suggests that getting Valgrind working with Wine would be much easier. Nick |
|
From: Tor L. <tm...@ik...> - 2009-03-28 21:25:22
|
>> (Also, kernel and C library source code is invaluable. That would be another
>> obstacle on Windows in particular.)
True. But OTOH there are lots of informative high-level articles about
Windows internals on the net, and books (I have a couple).
> the syscall interface between the kernel and user-space isn't well defined (ie. not public
> and subject to change).
Actually, I would say that has changed much since NT4 and Win2k days.
Most (?) of those system calls that would be interesting to valgrind
and its tools are documented either in the Windows SDK or WDK ("Driver
Kit") documentation (and also online on MSDN).
--tml
|
|
From: Nicholas N. <n.n...@gm...> - 2009-03-29 12:21:15
|
On Sat, Mar 28, 2009 at 4:25 PM, Tor Lillqvist <tm...@ik...> wrote:
>
> Actually, I would say that has changed much since NT4 and Win2k days.
> Most (?) of those system calls that would be interesting to valgrind
> and its tools are documented either in the Windows SDK or WDK ("Driver
> Kit") documentation (and also online on MSDN).
On Linux and Darwin, all system calls are interesting to Valgrind, and
I wouldn't expect Windows to be different.
Nick
|
|
From: Filipe C. <fi...@gm...> - 2009-03-29 15:17:57
|
Hi, Is there a list of tasks to be done? I could try to help in my spare time, but would have to know where to start. Regards, F Nicholas Nethercote wrote: > On Thu, Mar 26, 2009 at 9:10 PM, Greg Parker <gp...@ap...> wrote: >> Merging a Windows port to the existing repository would take time and >> effort. In particular, the portability infrastructure would need to be built >> up in some places where all current ports happen to be the same. > > To give you an idea, I've been working on merging Greg's Darwin port > for about 2 months now, with a couple of weeks of help from Julian, > and I would estimate we are roughly half way towards merging it with > the trunk. > > Nick > > ------------------------------------------------------------------------------ > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Nicholas N. <n.n...@gm...> - 2009-04-15 23:22:11
Attachments:
vg_test-annotated
|
On Mon, Mar 30, 2009 at 1:17 AM, Filipe Cabecinhas <fi...@gm...> wrote: > > Is there a list of tasks to be done? I could try to help in my spare time, > but would have to know where to start. I've been mostly working on getting the number of regtest failures down. Attached is the file I've been using to track them, it has explanations for most of them why they fail. Patches to fix any of the failing tests would be welcome, although beware that I'm working on them as well, and not in any particular order (but I'm mostly focusing on the Memcheck and Nulgrind ones) so there's potential for duplicating work. Better might be to look at comments in the branch code indicating things that need improvement. Search for comments containing "DDD" and "GrP". Another thing you could do is diff the DARWIN branch against the trunk, go through the diff and see if there's anything that looks like it could do with some improvement. The aim is to get the diff between the branch and the trunk to contain only clean, Darwin-only code, so that when the time comes to merge it will be as simple as possible, just dropping in all the extra Darwin pieces, if you see what I mean. Or you could run some big programs and fix any problems you find, like you did with your iTunes-enabling patch (which I'll hopefully get to shortly!) Thanks for asking, I hope this info is useful. Nick |