Thread: [Valgrind4win-developers] project status

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hey

i've found that project while I was looking for some informations in
the valgrind mailing list.

I would like to know is that project is still alive

thank you

Vincent Torri

Hi Vincent,

> I would like to know is that project is still alive.
The situation is more or less how it seems. We (if I can speak for
everyone involved, which can be as little as two people) are still
eager to have a fully working Valgrind on Windows and we have managed
to get it to a quite good state, being able to run simple console and
GUI applications emulated. But, of course, there are still many many
areas to improve.

There has been no activity in the last months because we seem to be
quite busy guys, but I for one want to continue working on it if the
time allows. As a matter of fact, I have been preparing some symbol
handling code rewrite for use in Valgrind (actually not limited to the
Windows port) during this time.

Kind regards,
Jiri

Hello

On Mon, Feb 4, 2013 at 2:18 PM, Jiří Hruška <ji...@fu...> wrote:
> Hi Vincent,
>
>> I would like to know is that project is still alive.
> The situation is more or less how it seems. We (if I can speak for
> everyone involved, which can be as little as two people) are still
> eager to have a fully working Valgrind on Windows and we have managed
> to get it to a quite good state, being able to run simple console and
> GUI applications emulated. But, of course, there are still many many
> areas to improve.

ok

> There has been no activity in the last months because we seem to be
> quite busy guys, but I for one want to continue working on it if the
> time allows. As a matter of fact, I have been preparing some symbol
> handling code rewrite for use in Valgrind (actually not limited to the
> Windows port) during this time.

Ok. I don't know much about writing those tools (though i have gebun
to write some similar tool using dll injection, api hooking and stack
traces. It works with Microsoft tools, but stack strace is not working
using binutils bfd library).

Actually, as i try to maintain windows port of some libraries, having
such a tool is very important. But i don't use eclipse and other IDE
(i use emacs), and even, cross compiling (using mingw-w64).

If you think it is worth the work, i can provide some autotools
support so that people can cross compile it on linux, or on windows
using MSYS. That, way, I (and maybe others, like valgrind guys ?) can
also provide some testing of the trunk.

Also, it is a shame that there is no publicity for that project. You
should ask valgrind guys to provide a link in the main valgrind web
page, send mails to OSnews, phoronix, slashdot, etc... This could
attract people who are porting libraries to Windows (like gnome or kde
guys ?)

best regards

Vincent Torri

On Mon, Feb 4, 2013 at 2:59 PM, Vincent Torri <vin...@gm...> wrote:
> Hello
>
> On Mon, Feb 4, 2013 at 2:18 PM, Jiří Hruška <ji...@fu...> wrote:
>> Hi Vincent,
>>
>>> I would like to know is that project is still alive.
>> The situation is more or less how it seems. We (if I can speak for
>> everyone involved, which can be as little as two people) are still
>> eager to have a fully working Valgrind on Windows and we have managed
>> to get it to a quite good state, being able to run simple console and
>> GUI applications emulated. But, of course, there are still many many
>> areas to improve.
>
> ok
>
>> There has been no activity in the last months because we seem to be
>> quite busy guys, but I for one want to continue working on it if the
>> time allows. As a matter of fact, I have been preparing some symbol
>> handling code rewrite for use in Valgrind (actually not limited to the
>> Windows port) during this time.
>
> Ok. I don't know much about writing those tools (though i have gebun
> to write some similar tool using dll injection, api hooking and stack
> traces. It works with Microsoft tools, but stack strace is not working
> using binutils bfd library).
>
> Actually, as i try to maintain windows port of some libraries, having
> such a tool is very important. But i don't use eclipse and other IDE
> (i use emacs), and even, cross compiling (using mingw-w64).
>
> If you think it is worth the work, i can provide some autotools
> support so that people can cross compile it on linux, or on windows
> using MSYS. That, way, I (and maybe others, like valgrind guys ?) can
> also provide some testing of the trunk.
>
> Also, it is a shame that there is no publicity for that project. You
> should ask valgrind guys to provide a link in the main valgrind web
> page, send mails to OSnews, phoronix, slashdot, etc... This could
> attract people who are porting libraries to Windows (like gnome or kde
> guys ?)

Also, imho, you should send mails to at least the mailing lists of :
MinGW, mingw-w64, cygwin, Wine and ReactOS about that project

regards

Vincent Torri

Hey

the lead developper of mingw-w64 just told me that mingw-w64 might be
able to add specific options to startup/runtime-code, if it would be
profitable for valgrind4win venture

in case it interests you.

regards

Vincent Torri

On Mon, Feb 4, 2013 at 3:03 PM, Vincent Torri <vin...@gm...> wrote:
> On Mon, Feb 4, 2013 at 2:59 PM, Vincent Torri <vin...@gm...> wrote:
>> Hello
>>
>> On Mon, Feb 4, 2013 at 2:18 PM, Jiří Hruška <ji...@fu...> wrote:
>>> Hi Vincent,
>>>
>>>> I would like to know is that project is still alive.
>>> The situation is more or less how it seems. We (if I can speak for
>>> everyone involved, which can be as little as two people) are still
>>> eager to have a fully working Valgrind on Windows and we have managed
>>> to get it to a quite good state, being able to run simple console and
>>> GUI applications emulated. But, of course, there are still many many
>>> areas to improve.
>>
>> ok
>>
>>> There has been no activity in the last months because we seem to be
>>> quite busy guys, but I for one want to continue working on it if the
>>> time allows. As a matter of fact, I have been preparing some symbol
>>> handling code rewrite for use in Valgrind (actually not limited to the
>>> Windows port) during this time.
>>
>> Ok. I don't know much about writing those tools (though i have gebun
>> to write some similar tool using dll injection, api hooking and stack
>> traces. It works with Microsoft tools, but stack strace is not working
>> using binutils bfd library).
>>
>> Actually, as i try to maintain windows port of some libraries, having
>> such a tool is very important. But i don't use eclipse and other IDE
>> (i use emacs), and even, cross compiling (using mingw-w64).
>>
>> If you think it is worth the work, i can provide some autotools
>> support so that people can cross compile it on linux, or on windows
>> using MSYS. That, way, I (and maybe others, like valgrind guys ?) can
>> also provide some testing of the trunk.
>>
>> Also, it is a shame that there is no publicity for that project. You
>> should ask valgrind guys to provide a link in the main valgrind web
>> page, send mails to OSnews, phoronix, slashdot, etc... This could
>> attract people who are porting libraries to Windows (like gnome or kde
>> guys ?)
>
> Also, imho, you should send mails to at least the mailing lists of :
> MinGW, mingw-w64, cygwin, Wine and ReactOS about that project
>
> regards
>
> Vincent Torri

Hi Vincent,

> the lead developper of mingw-w64 just told me that mingw-w64 might be
> able to add specific options to startup/runtime-code, if it would be
> profitable for valgrind4win venture
One of the useful properties of Valgrind is that it is compiler
agnostic, being able to work with binaries across used tools, vendor,
source code availability etc. As long as the compiler/toolchain
produces useful debugging info, everything is OK.

> Also, it is a shame that there is no publicity for that project. You
> should ask valgrind guys to provide a link in the main valgrind web
> page, send mails to OSnews, phoronix, slashdot, etc... This could
> attract people who are porting libraries to Windows (like gnome or kde
> guys ?)
> Also, imho, you should send mails to at least the mailing lists of :
> MinGW, mingw-w64, cygwin, Wine and ReactOS about that project
Yes, those kind of things would be nice, although I believe it would
be good to have the project in a certain state before this level of
publicity. If anyone hears about it, the first question would be
"where can I download it", then "pah, it doesn't run even my simplest
application". Having regular working builds, which are able to run all
(most of) code on all supported platforms (x86, x64, wow64) with
nullgrind would be good. More or less how Christoph described the
"alpha phase" on this page:
http://sourceforge.net/p/valgrind4win/wiki/ProjectStatus/

This state is actually not so far as it might seem, IIRC. What's
needed is a thorough review of syscall and kernel callback mechanisms
on all the platforms and fixing any major bugs, which appear often
during real world usage. That also means having a proper PDB support,
which I have been working on.

Also I've spoken with Julian Seward et. al. regarding the possible
upstream merge and other stuff. In my opinion, the good time to
discuss in detail whether we are doing all this right or wrong will be
again in the aforementioned alpha state, when everything is roughly
working and we can just refactor the individual parts if needed,
retaining the functionality.

Kind regards,
Jiri

On Tue, Feb 5, 2013 at 10:48 PM, Jiří Hruška <ji...@fu...> wrote:
> Hi Vincent,
>
>> the lead developper of mingw-w64 just told me that mingw-w64 might be
>> able to add specific options to startup/runtime-code, if it would be
>> profitable for valgrind4win venture
> One of the useful properties of Valgrind is that it is compiler
> agnostic, being able to work with binaries across used tools, vendor,
> source code availability etc. As long as the compiler/toolchain
> produces useful debugging info, everything is OK.
>
>> Also, it is a shame that there is no publicity for that project. You
>> should ask valgrind guys to provide a link in the main valgrind web
>> page, send mails to OSnews, phoronix, slashdot, etc... This could
>> attract people who are porting libraries to Windows (like gnome or kde
>> guys ?)
>> Also, imho, you should send mails to at least the mailing lists of :
>> MinGW, mingw-w64, cygwin, Wine and ReactOS about that project
> Yes, those kind of things would be nice, although I believe it would
> be good to have the project in a certain state before this level of
> publicity. If anyone hears about it, the first question would be
> "where can I download it", then "pah, it doesn't run even my simplest
> application". Having regular working builds, which are able to run all
> (most of) code on all supported platforms (x86, x64, wow64) with
> nullgrind would be good. More or less how Christoph described the
> "alpha phase" on this page:
> http://sourceforge.net/p/valgrind4win/wiki/ProjectStatus/
>
> This state is actually not so far as it might seem, IIRC. What's
> needed is a thorough review of syscall and kernel callback mechanisms
> on all the platforms and fixing any major bugs, which appear often
> during real world usage. That also means having a proper PDB support,
> which I have been working on.
>
> Also I've spoken with Julian Seward et. al. regarding the possible
> upstream merge and other stuff. In my opinion, the good time to
> discuss in detail whether we are doing all this right or wrong will be
> again in the aforementioned alpha state, when everything is roughly
> working and we can just refactor the individual parts if needed,
> retaining the functionality.

ok.

And what about the autotools stuff ?

Vincent Torri

> And what about the autotools stuff ?
Valgrind uses autotools exclusively as its build system and the
Windows port is no different. We use MSYS with MinGW-w64 (or maybe
other MinGW variants on top) for building.
To be honest I'm not sure whether a crosscompilation on Linux would be
possible, but I can't see any reason why not. I know Christoph have
some script to check whether the Valgrind4win codebase builts exactly
the same binary as the original Valgrind when Windows platform stuff
is turned off in configure, to make sure the changes are correctly
#ifdef'ed, but that's all.

Kind regards,
Jiri

On Wed, Feb 6, 2013 at 12:13 AM, Jiří Hruška <ji...@fu...> wrote:
>> And what about the autotools stuff ?
> Valgrind uses autotools exclusively as its build system

hmm, then I don't understand what is in

http://sourceforge.net/p/valgrind4win/wiki/DevelopmentEnvironment/

:)

Vincent Torri

> and the
> Windows port is no different. We use MSYS with MinGW-w64 (or maybe
> other MinGW variants on top) for building.
> To be honest I'm not sure whether a crosscompilation on Linux would be
> possible, but I can't see any reason why not. I know Christoph have
> some script to check whether the Valgrind4win codebase builts exactly
> the same binary as the original Valgrind when Windows platform stuff
> is turned off in configure, to make sure the changes are correctly
> #ifdef'ed, but that's all.
>
> Kind regards,
> Jiri
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> Valgrind4win-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind4win-developers

Hi Vincent,

> hmm, then I don't understand what is in
> http://sourceforge.net/p/valgrind4win/wiki/DevelopmentEnvironment/
Oh, well Christoph is using Eclipse, I forgot about that, sorry!
I'm using the usual way though, like in the last chapter on that page,
and it's working fine.

Jiri

Having some progress on this would be great.

On 02/05/2013 10:48 PM, Jiří Hruška wrote:
> upstream merge and other stuff. In my opinion, the good time to
> discuss in detail whether we are doing all this right or wrong will be
> again in the aforementioned alpha state, when everything is roughly
> working and we can just refactor the individual parts if needed,
> retaining the functionality.

I agree.

Is there anything specific that can be done to help move this along?

I was also wondering if it might not be better to use the main V dev
list for discussions.  In that way you'd reach a somewhat wider audience
of developers.  Or at least, send periodic status reports to the main
dev list, so as to make people aware that the valgrind4win list
exists, and that there is activity.

J

Hi Julian,

> Having some progress on this would be great.
> Is there anything specific that can be done to help move this along?
Well, the project has been more or less idle for the past months...
The other guy has been apparently busy as me and everybody else and
I've been dealing with a single issue - there were a lot of problems
just because of bad symbols (useless reports due to wrong stack
traces, mismatched redirections, crashes due to unknown file format,
pulling a big DLL with many dependencies just to find the .pdb file
path), so I've been working on a proper PDB reader. It's not finished
yet, but I'd call it the most accurate non-MS PDB implementation out
there already.

My understanding of the other parts of the port got a bit rusty in the
meantime, but I will probably have some more free time in the upcoming
weeks, maybe even this weekend, so I'll try to make an updated
overview of what's working, what needs to be (re)done etc., so it is
possible to coordinate further work and know what's missing from at
least an alpha-quality release.

One problem even in the long term might be that there are probably not
too many hackers understanding a bit of all, Valgrind architecture,
assembler, reverse engineering, Windows internals etc. AND enough time
on their hands to get involved. The commit log and me being the only
one active on this mailing list at the moment speaks for itself.
Hopefully when the low-level stuff is done, there will be smaller and
more mundane tasks than "implement kernel callbacks" for more people
to contribute. For me personally, this is maybe the most interesting
project I've been dealing with in the long time and I would love to
devote more to it, but it's been just hard to find the time for it
recently. Maybe I should find some big company which would like to see
this through as a sponsor, heh.

> I was also wondering if it might not be better to use the main V dev
> list for discussions.
Yes, that might be a good idea, there is little going on here anyway.
When I'll make that some kind of a report, I'll crosspost it there.
Of course any discussions about the proper implementation of the
individual parts the port, possible upstream merge etc. are naturally
fit for the main V-dev list or IRC too.

Jiri

Hi all,

let me add to the topics discussed so far:

1) project status
There are only three developers who made significant contributions to 
this project: TML, Jiri and myself. Sadly I didn't have time in the last 
months to work on this project. The last check-in dates from August 
2012. So yes the project is pretty much idle, but it's definitely not dead.

2) project announcement on various mailing lists or web sites
No problem with that. However it should be made clear that the project 
at this time needs developers only. This means people who want to work 
on the project itself (="developers"), not people who want to use it to 
test their software (="users"). The latter will result in disappointment 
only because the project is just not ready for it.

And BTW I don't want users to build V4W. Whenever there is a V4W 
release, it will be via installer packages just like any other Windows 
software. This saves the users frustration in having to deal with 
setting up a development environment and building the software, and 
frees the developers from assisting users in such tasks.

3) upstream merge
I agree with what has been said. The earliest point when one could think 
about merging the two projects would be the "Alpha" state. However, 
separate development could also continue until a "Beta" or even later 
stage. There is a process how to merge changes from upstream to V4W and 
I can do this whenever necessary.

4) cross-compilation on Linux
This will be significant effort and I don't see a benefit coming from 
this. This is mainly because in order to test any changes you do need 
Windows. So why not build V4W on Windows in the first place? All tools 
required for this are 100% free (MinGW, GCC, autotools, MS SDK, etc.) 
and there is documentation how to set up a development system.

Chris